Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] state:modified should include check_modified_contract #11034

Closed
2 tasks done
Tracked by #10125
jtcohen6 opened this issue Nov 22, 2024 · 0 comments · Fixed by #11161
Closed
2 tasks done
Tracked by #10125

[Bug] state:modified should include check_modified_contract #11034

jtcohen6 opened this issue Nov 22, 2024 · 0 comments · Fixed by #11161
Assignees
Labels
backport 1.9.latest bug Something isn't working model_contracts state: modified state Stateful selection (state:modified, defer)

Comments

@jtcohen6
Copy link
Contributor

jtcohen6 commented Nov 22, 2024

Is this a new bug in dbt-core?

  • I believe this is a new bug in dbt-core
  • I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

Following the implementation in:

If I delete/rename a contracted model, I expect to see a warning/error when I dbt <command> --select state:modified.

But I only see this warning/error with dbt <command> --select state:modified.contracts

Expected Behavior

state:modified should include check_modified_contract: 14453eb

@T-Dunlap:

It's going to be really difficult to educate customers that they have to explicitly call out state:modified.contract in their CI jobs. It's best if this is baked directly into state:modified

@joellabes:

my understanding was that state:modified contained everything the more granular state:modified.* methods offered (and then some) and would not at all expect that there was something only available with a submethod

Steps To Reproduce

  1. I deleted the model and all references to the model in the project.
  2. I deleted the contract, which contained two versions
  3. My downstream project was pointed to v1, which was technically deprecated.
  4. No downstream models were pointed to v2.
  5. No error or warning.

Relevant log output

No response

Environment

dbt: 1.9 / Versionless

Which database adapter are you using with dbt?

No response

Additional Context

Would this require a behavior-change flag? I don't think so, because it feels in keeping with the original intent of the issue, with what we've documented, and with what users would expect to happen

It also generally crops up in CI jobs, so unlikely to suddenly break someone's prod runs unless they're actually proposing code changes. (I think they'd need to be doing something wacky with dynamically enabling/disabling contracted versioned models)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 1.9.latest bug Something isn't working model_contracts state: modified state Stateful selection (state:modified, defer)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants