[CT-3289] [Feature] Common misspellings of Configs Are Silently Ignored - they should raise warnings

[graciegoheen]

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

Users can pass whatever custom configs they want. There have been issues because of this before...
#5605
#4280
#2606

where folks are trying to add a Real config, but have a small typo that causes it to go undetected:

• known common mistakes like:
  • 'materialization' instead of 'materialized'
  • 'error' instead of 'error_if'
  • 'test' instead of 'tests'
• typos of expected keys like 'materialied' instead of 'materialized'. There are fancy but easy to implement ways like "edit distance" to detect this.

(og thinking from @peterallenwebb and @jtcohen6)

Acceptance Criteria

1. Post validation we should check configs for "possible misspellings"
2. For identified "possible misspellings" a warning should be issued that looks like We detected a key "<misspelled_key>" did you mean "<correct_spelling>"
3. The warning type should be silence-able

Details

We should throw a warning anytime you supply a config that we don't actually use. (see original conversation about this)

If I have a config that dbt doesn't use:

models:
  - name: some_model
    invalid_key:
      - something
    columns:
      - name: id
        my_personal_key:
          - something_else

We should emit a warning like "my_personal_key is not recognized as a dbt config within models/columns" - probs need to wordsmith that ;)

We should provide the ability to silence this warning if it is indeed intentional, ideally for that specific instance. Similar in spirit to:

• [Feature] An option to silence warnings #9644
• [CT-3430] [Feature] dbt should tell me if a custom macro in my project overrides one in the global project or my adapter #9164

We could suggest what they may have intended to type "did you mean materialized instead of materialied?" if we wanna get fancy with it.

[graciegoheen]

Instead, we could throw a warning anytime you supply a config that we don't actually use. (see original conversation about this)

If I have a config that dbt doesn't use:

models:
  - name: some_model
    invalid_key:
      - something
    columns:
      - name: id
        my_personal_key:
          - something_else

We should emit a warning like "my_personal_key is not recognized as a dbt config within models/columns" - probs need to wordsmith that ;)

We should provide the ability to silence this warning if it is indeed intentional, ideally for that specific instance. Similar in spirit to:

• [Feature] An option to silence warnings #9644
• [CT-3430] [Feature] dbt should tell me if a custom macro in my project overrides one in the global project or my adapter #9164

We could suggest what they may have intended to type "did you mean materialized instead of materialied?" if we wanna get fancy with it.

[joellabes]

+1 to this from Jenna

[danielhorvath-cleo]

+1 from me as well.

I literally spent hours recently debugging why incrementalisation doesn't work properly on one model, only to find out I typed unqiue_key in the config.

In the meantime, what's the best practice to guard against such errors?

[boxysean]

[joellabes]

dbt_project.yml isn't called out here, but it should be included too I think! cf dbt-labs/dbt-jsonschema#179