agent patched a macro but dbt used the stale parse cache

TL;DR

Partial parsing caches macro definitions, and an edit made in a way the cache does not detect (or a copied target folder) leaves dbt compiling with the old macro. Force a fresh parse: delete target/ (or run with the no-partial-parse flag) after macro edits, and have the agent do this automatically whenever a file under macros/ changes.

agent patched a macro but dbt used the stale parse cache

Use this when

• an agent edited a macro but compiled SQL still shows the old macro behavior
• dbt logs mention partial parsing or reusing the previous manifest
• the target folder was copied between machines or restored from a cache

Not for this skill when

• the edit went to a different macro file with the same name in another folder, resolve that path issue instead
• the macro being called is the package version, not your override, fix dispatch or override placement
• compiled SQL changed but runtime behavior did not, the issue is downstream of compilation

Steps

1. Confirm staleness: add no logic change yet; run dbt compile --select on a calling model and grep the compiled SQL for a marker from the new macro version (or the absence of the old one). Note whether dbt reported partial parsing. Verify: you have evidence whether the new macro is in effect.

2. Force a full parse: run the compile again with the --no-partial-parse flag (or delete target/partial parse cache files and target/manifest files, then compile). Verify: compiled SQL now shows the new macro output.

3. Bake the rule into the agent: any change under macros/ (and any change to dbt_project.yml) triggers a no-partial-parse compile for verification steps. Verify: the agent workflow forces full parse after macro edits.

4. Run the affected models and their tests to confirm behavior matches the new macro, not just its text. Verify: run and test results reflect the patched macro.

Variant phrasings

stale in CI only

CI caches target/ between runs to save time. Key the cache on macro and project file hashes, or exclude partial parse state from the cache.

dbt Cloud stale behavior

Cloud keeps its own parse state per environment. A deferral or version mismatch can mimic staleness; verify with a fresh environment run before blaming the cache.

Compatibility: dbt-core partial parsing, 1.x (enabled by default in several versions, controlled by flags and env vars). Cache state lives in target/ including partial_parse.msgpack on newer versions.

Why it happens

Partial parsing exists to make large projects fast: dbt records file hashes and macro definitions and skips re-reading what it believes is unchanged. When a file changes through a path the hasher misses, or state is restored inconsistently, the recorded macro and the file on disk diverge, and compiles faithfully use the recorded (old) macro until a full parse rebuilds state.

Edge cases / pitfalls

• Deleting target/ also deletes run artifacts other steps may expect; sequence full parses before runs that produce needed artifacts.
• Do not disable partial parsing globally for everyone because of one agent bug; scope the forced parse to post-macro-edit verification.
• Version upgrades can invalidate cache formats; a one-time full parse after upgrading dbt is cheap insurance.

Provenance

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