[Feature] Always raise warnings in every invocation, even if partial parsing is used

[mwstanleyft]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

dbt sometimes raises warnings at parse time, such as tests that reference missing relations, or model configuration nodes in dbt_project.yml that refer to folders that do not exist.

On subsequent invocations, if parsing steps are skipped because partial parsing is used, then these warnings aren't re-raised, which gives the false impression that the condition that caused the warning has been resolved, when in fact the warning condition still exists.

dbt should raise parsing-related warnings on all invocations even if partial parsing means that parsing was skipped.

Describe alternatives you've considered

No response

Who will this benefit?

Anyone who encounters a parsing-related warning in dbt and is confused about why the warning message is inconsistent (see for example https://getdbt.slack.com/archives/CBSQTAPLG/p1718056852222639)

Are you interested in contributing this feature?

No

Anything else?

No response

[dbeatty10]

Thanks for suggesting this @mwstanleyft 💡 !

@dataders, @jtcohen6, and myself got a chance to discuss this today, and we agree that:

• dbt should raise parsing-related warnings on all invocations even if partial parsing means that parsing was skipped.

This would give users consistent and repeatable warnings regardless if partial parsing is used or not. Then users can configure warn_error_options on a warning-by-warning basis to leave as-is, silence, or promote to an error.

[QMalcolm]

So this is possible, but it's unfortunately not as easy as "just emit the events". Parsing events are emitted when they are encountered. Said another way, for parsing events, we emit the warning when we find the issue at parse time. During partial parsing, files that haven't changed are skipped, and thus not parsed. Consequently, no warnings are emitted for issues in skipped files because the issue isn't encountered.

That said, we have a FileBlock object, and the list of FileBlocks are part of the manifest (as they're needed for partial parsing). We could begin saving parsing issues that are encountered to the relevant FileBlock at parse time. Then when a FileBlock is identified as skipped, we could re-emit the saved warnings. However, this would increase the size of the manifest. By how much depends on how many warnings a given project has. It could potentially balloon it a lot

[github-actions]

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days.

[github-actions]

Although we are closing this issue as stale, it's not gone forever. Issues can be reopened if there is renewed community interest. Just add a comment to notify the maintainers.