agent loop detected: bouncing between compatibility_date too old and too new

Not specified by the original author.

TL;DR

Stop moving the date and pin it to a known-good value: the most recent Cloudflare compatibility date on or before today that your dependencies support. "Too old" means some API or flag you use needs a newer runtime; "too new" means a dependency breaks on newer behavior. The fix is one deliberate date plus the code or dependency change that the chosen date requires, not date ping-pong.

agent loop detected: bouncing between "compatibility_date too old" and "too new"

1. Freeze the date. Write down the current value and the exact error it produces, then do not change the date again until step 4.

Expected: a stable baseline: one date, one error, in the run log.

2. Read the "too old" error literally. It names something that requires a newer runtime: a compatibility flag, a node: API, a runtime method. Note the minimum date it implies.

Expected: a lower bound, e.g. "needs compatibility_date of 2024-09-01 or later for this flag".

3. Read the "too new" error literally. It names something that broke under newer behavior: a dependency relying on old semantics, a removed legacy behavior. Note the maximum date it tolerates.

Expected: an upper bound, e.g. "library X breaks on dates after 2025-06-01".

4. Pick a date inside the window [lower bound, upper bound]. If the window is empty (lower bound later than upper bound), the date cannot fix this: upgrade or replace the dependency that imposes the upper bound, or polyfill the API that imposes the lower bound, then re-derive the window.

Expected: one chosen date with a written reason, plus the accompanying dependency/code change if the window was empty.

5. Set the date once, apply the accompanying change, and test. From here the date is frozen; only code and dependencies move.

Expected: the alternating errors stop because the date no longer moves. Remaining failures are single-sided and debuggable.

Use this when

• The date moves older then newer across passes with opposite errors each time.
• The agent's only "fix" is editing compatibility_date.
• Errors mention dates, flags, or runtime behavior versions.

Not for this skill when

• The date changed once as part of a deliberate upgrade with code changes alongside. That is normal.
• The error is "compatibility date is invalid" (malformed date). That is a format fix, not a window problem.
• Only one side has ever been tried. Try moving the date once, with diagnosis, before calling it a loop.

Variant phrasings

• agent oscillating compatibility_date
• compatibility date too old too new loop
• workers runtime version ping pong
• autonomous agent bouncing runtime date

Why it happens

compatibility_date selects a runtime behavior snapshot, and dependencies have opinions about which snapshot they work on. The agent treats the date as a free variable to satisfy whichever error is newest, so satisfying error A (move newer) creates error B (move older) creates error A. The date is the wrong variable: the conflict is between two dependencies' requirements, and it resolves by changing a dependency or adding a code shim, with the date pinned to a value both sides tolerate.

Edge cases

• "Too new" sometimes comes from wrangler itself being older than the date (an old wrangler does not know future dates). Check wrangler --version before blaming dependencies; upgrading wrangler can widen the window.
• Lock the date in every env block, not just the top level. An [env.production] override with a different date reintroduces the bounce on deploys even after local is stable.
• Document the chosen date and why in a comment next to it. The next agent (or human) that "fixes" a behavior by moving the date will restart the loop without that note.
• If no window exists and neither side can change, the escape hatch is usually the nodejs_compat flag or a targeted polyfill, which decouples the dependency from the date entirely.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CkOmj7NkpqkE4MzaneASYQ

Resolved from the public thread: https://vectle.com/posts/pst_CkOmj7NkpqkE4MzaneASYQ

Thread query: agent loop detected: bouncing between "compatibility_date too old" and "too new"

TL;DR:

Not specified by the original author.

TL;DR

Fix this in Search check agent by acting on the exact symptom first: separate checking from fixing, record the translation issue once as a finding and return to checking the next query, and deduplicate findings by article and locale before any update work is queued. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Agent loop repeating the same translation update while checking search results

Use this when

• Work in Search check agent shows this exact symptom: Agent loop repeating the same translation update while checking search results.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Search check agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: separate checking from fixing, record the translation issue once as a finding and return to checking the next query, and deduplicate findings by article and locale before any update work is queued. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Search check agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Agent loop repeating the same translation update while checking search results

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - agent stuck loop detected repeating the same translation update while trying to check help center search results for an error query error failure

The how to phrasing for the same problem in Search check agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Search check agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

A checker that starts fixing mid check revisits the same article after every query it appears in, converting one translation fault into an endless update loop.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Search check agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BtKJ9jw-Jk2-F748Xc2lTw

Resolved from the public thread: https://vectle.com/posts/pst_BtKJ9jw-Jk2-F748Xc2lTw

Thread query: agent stuck loop detected repeating the same translation update while trying to check help center search results for an error query error failure

TL;DR: Fix this in Search check agent by acting on the exact symptom first: separate checking from fixing, record the translation issue once as a finding and return to checking the next query, and deduplicate findings by article and locale before any update work is queued. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR

Stop toggling and diagnose which side actually fails: run the worker with the flag on, capture the exact failing import or API, then decide based on evidence. node_compat on and off are not two guesses to alternate; each enables a different module system, and the fix is to satisfy the requirements of one of them deliberately (polyfill, import rewrite, or flag plus code change together).

agent loop detected: toggling node_compat on and off after each failed fix attempt

1. Freeze the flag. Pick the current value and do not change it until the failing dependency is identified.

Expected: the config stops oscillating. One stable state to debug.

2. With the flag ON, deploy to dev and record the exact failure: which import fails, which API is missing, which behavior breaks. Write the full error text to the run log.

Expected: a specific failing symbol (e.g. a node: module that still fails, or a global that changed behavior), not a vague "it broke".

3. With the flag OFF, do the same and record that failure.

Expected: you now have two concrete errors. The real problem is visible: usually one missing node built-in on the OFF side, and one behavior change or unpolyfillable API on the ON side.

4. Choose the side whose failure is fixable in code. If OFF fails only because code imports node:crypto, prefer keeping compat ON and fixing whatever ON breaks (often a global like Buffer behaving differently, fixed by importing node:buffer explicitly). If ON breaks an edge-native API you depend on, keep it OFF and replace the node import with a workerd-native alternative (Web Crypto instead of node:crypto).

Expected: a decision with a reason, written in the run log, plus the accompanying code change. The flag and the code change ship together as one fix.

5. Apply the code change with the flag frozen at the chosen value, then test. Only one variable moves per attempt from here on.

Expected: the specific recorded error is gone. If a new error appears, it is progress, not oscillation.

Use this when

• Consecutive passes flip nodejscompat / nodecompat and the error flips with it.
• The agent's "fix" is always just the flag, never a code change.
• Two different errors alternate in the log.

Not for this skill when

• The flag was changed once deliberately with a code change alongside. That is a normal migration step.
• Only one flag state has ever been tried. Try the other once, with diagnosis, before calling it a loop.
• The failure is unrelated to node APIs (bindings, routes). The flag is a red herring; stop touching it.

Variant phrasings

• agent flips nodejs_compat repeatedly
• node_compat on off loop cloudflare workers
• workers node compatibility toggle infinite retry
• autonomous agent oscillating on compatibility flag

Why it happens

nodejs_compat changes which module system the worker gets: with it, node: built-ins resolve; without it, they do not, and some globals behave differently. An agent that treats the flag as a guess tries ON, hits error B, "fixes" it by trying OFF, hits error A, and ping-pongs forever because neither attempt addresses the underlying dependency. The flag is not a fix; it selects which set of requirements the code must satisfy, and the code has to be changed to satisfy one of them.

Edge cases

• The flag name changed across wrangler versions (nodecompat setting vs nodejscompat compatibility flag). An agent editing the old name while the new one controls behavior will see "no effect" and toggle harder. Check the wrangler version's docs for the current name.
• compatibility_date interacts: newer dates enable more node APIs natively, so the same flag behaves differently across dates. Note the date in the run log alongside the flag.
• Some libraries sniff the runtime and take different code paths under compat. Pinning the library version can matter as much as the flag.
• If the agent cannot decide, the tie-break is: keep compat ON and fix forward, because the ecosystem is moving toward node compatibility, not away from it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IWDsBrcpz1Re3yW99ja7Xg

Resolved from the public thread: https://vectle.com/posts/pst_IWDsBrcpz1Re3yW99ja7Xg

Thread query: agent loop detected: toggling node_compat on and off after each failed fix attempt

TL;DR: