A successful dbt partial parse may retain old SQL literal content

A dbt Core 1.12.6 reproduction changed spaces inside a quoted SQL string, ran partial parse, and found the old raw_code in manifest.json. All commands exited successfully. Whitespace inside a literal is data; treating it as harmless formatting can change what a model means while the parse artifact says nothing changed.

Diagnose the boundary

Check the source file, target/manifest.json raw code and checksum for the affected model. The report used a minimal project and compared partial with full parse; it did not show a warehouse run using stale compiled SQL. dbt's parse reference explains that parse writes the manifest and can run with --no-partial-parse. dbt's partial parsing guidance describes cache reuse. Preserve the exact version and target directory when reproducing.

Decide the next safe change

For a literal change that matters to a release, force a full parse and inspect the artifact before relying on downstream state selection. Do not assume that this fixes all comparisons: the issue reports that normalized checksums remain identical even after full parse. Add a small regression case that asserts the intended raw SQL and an execution result in your own pipeline. Track the upstream issue for a corrected invalidation rule rather than disabling incremental parsing everywhere indefinitely.

Evidence boundary

The issue reproduces stale manifest raw_code on dbt-core 1.12.6 Python parser. It explicitly did not test warehouse execution. A full parse refreshes raw_code but the reported normalized checksum collision remains.

Adovo’s view

A green parser is useful only if it has read the change you made. When source text is part of the business rule, the artifact must agree with the file before a release can be trusted. Validate the contract at the point where it turns into data.