agent regenerated the client after the docs updated - the old generated code was still cached and got deployed instead

TL;DR

Invalidate the build cache (or bypass it) and verify the deployed artifact contains the new generated code. Regenerating means nothing if the pipeline ships the cached copy. Fix the cache, then prove the artifact changed.

agent regenerated the client after the docs updated  -  the old generated code was still cached and got deployed instead

Steps

1. Prove the deploy is stale. Diff the deployed client bundle against the freshly generated output, or check one method signature that changed between the old and new generation. Expected: you have concrete evidence the artifact is the old code.
2. Find which cache served the stale copy: dependency cache, docker layer cache, CI artifact cache, or the generator's own output directory. Expected: you can name the layer that skipped regeneration.
3. Clear that cache and re-run the pipeline, or pin the generation step to always run from a clean checkout in this workflow. Expected: the new run produces an artifact whose signature matches the fresh generation.
4. Verify post-deploy: hit one changed endpoint and confirm the new request shape goes out on the wire. Expected: live traffic shows the new behavior, not the old.
5. Make the pipeline cache-proof: hash the generator inputs (spec, template, generator version) into the cache key, or disable caching for the generation step. Expected: the cache key changes whenever the inputs change.

Use this when

• The docs or spec changed, you regenerated, and production still shows old request shapes.
• A scaffolder agent ran the generator successfully but the deploy pipeline reused cached artifacts.
• You own the CI/CD pipeline and can change caching behavior.

Not for this skill when

• The API itself drifted (the client is new, the API changed) - that is a spec-freshness problem, not a cache problem.
• The code was hand-written, not generated - caching the wrong source is a different issue.
• Regeneration never actually ran - check that first before blaming the cache.

Variant phrasings

• regenerated API client but deploy still uses cached old version
• CI served stale generated client code after spec update
• old generated client deployed despite successful regeneration

Why it happens

Build caches key on inputs they know about (package files, lockfiles). A spec URL or docs page is rarely part of the key, so regeneration runs in one step while a later cached step ships the previous output. Docker layer caches are the classic offender: if the COPY order puts the spec after the generation layer, the layer never rebuilds.

Edge cases

• Generator tools that write to a shared output dir but only overwrite changed files - stale removed files linger; wipe the output dir first.
• Lockfile or template-version pins that silently roll the generator back to an older version while the spec is new.
• Monorepos where the cache key covers the wrong package path and sibling packages poison the client build.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ANolz3mjjyIOOXywQ-0PFg