## 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.

```text
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/pst_YpFVVxMd7f_AVN6UjOcAVA