agent timed out waiting for the new worker version to serve traffic: routes still pointing at the old bundle

TL;DR

The deploy published a new version, but the route still serves the old one: gradual rollouts, a pinned version, or a route attached to a different worker. The agent waits for traffic that will never come. Check which version the route actually serves, fix the routing or rollout state, and verify with a version-identifying response header.

The query

agent timed out waiting for the new worker version to serve traffic: routes still pointing at the old bundle

Use this when

• Deploy succeeds but the live behavior is unchanged.
• The agent polls the URL waiting for new behavior.
• Minutes pass with no change.

Not for

• DNS propagation delays (different layer).
• Failed deploys (nothing was published).
• Cached old responses (purge or bypass cache to check).

Steps

Step 1: Identify the serving version

Add a version header or endpoint to the worker, then check what the route returns.

return new Response("ok", { headers: { "x-worker-version": VERSION } });

Expected result: the live version string. If it names the old version, routing is the problem, not propagation.

Step 2: Check rollout and version pinning

Gradual deployments, traffic splitting, or a pinned version keep old code serving by design.

Expected result: you see the rollout state. A 0%-traffic new version explains everything.

Step 3: Verify the route attachment

Confirm the route pattern attaches to THIS worker and this environment's name.

Expected result: the route points where you think. A staging-named worker with the production route (or vice versa) serves the 'wrong' version indefinitely.

Step 4: Complete the rollout or fix the route

Promote the version to full traffic or correct the route attachment, then re-check the version header.

Expected result: the live version string matches the just-deployed version.

Step 5: Make version visibility permanent

Expected result: every deploy is verifiable in one curl. The agent never again waits on behavior; it checks the version header.

Why it happens

'Deployed' and 'serving' are different states in systems with versions, rollouts, and routes. Agents treat deploy success as traffic success and poll the URL for change. When routing pins the old version, the poll never converges and the timeout is the only signal.

Edge cases

• Cache can also serve the old version. Bypass cache (or purge) before concluding it is a routing problem.
• Multiple routes can attach to one worker; check all of them, not just the one you tested.
• Preview URLs serve the new version while the custom domain serves old. Test the exact URL the agent polled.
• Rollback also goes through the same version machinery; verify rollbacks with the header too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgOYzJI-Pd-7gE9LqaO6wg