jtcohen6
commented
2 years ago @saraleon1 Thanks for opening!
If the only error had been defining the test as not null instead of not_null, we would have raised a more helpful error message (still not amazing, but at least better):
Compilation Error in test not_model_a_id (models/schema.yml)
'test_not' is undefined. This can happen when calling a macro that does not exist. Check for typos and/or install package dependencies with "dbt deps".The misspelled desciption and colums are more insidious. It's pretty surprising that this doesn't raise a validation error:
version: 2
models:
- name: model_a
random_key: does nothing@gshank I know we do basic validation for the models block when reading files, to make sure we're not setting parsing up for horrible failure later on. Do you have a sense of where we could validate to make sure that the keys in a node update block match our expected/supported keys? It's not like random_key is doing anything above; it doesn't appear as a node property in the manifest.
I haven't looked into this code extensively, but my sense is that we do one of the following:
- Change a low-level class to no longer be extensible / supporting additional properties
- Since unrecognized fields get popped into the
_extradict, raise a parsing error somewhere here? if there are unrecognized top-level keys:if block.target._extra: raise ParsingException(f"Extra keys not allowed! {block.target._extra}")$ dbt --no-partial-parse test 16:35:29 | [ info ] | Running with dbt=1.0.0-rc1 16:35:29 | [ error ] | Encountered an error: Parsing Error Extra keys not allowed! {'random_key': 'does nothing'}
I do think this could be a potential breaking change, in the sense of raising an error for existing projects that have cruft or misspelled properties hanging around. This feels like a great thing to sneak in for v1.0.0 if it would be simple, or a later minor version if it would be a much larger lift.
gshank
jeremyyeo
nathaniel-may
will-sargent-dbtlabs
github-actions[bot]
mazinesy
Is there an existing issue for this?
Current Behavior
A PR jobs started failing with no clear error message available to the end user. The only error surfaced was:
upon inspection of debug logs, the following log line was identified:
and upon inspection of more robust logging available to dbt cloud support, this stack trace was identified:
From here, we compared git changes between this PR job and the previously successful PR job, and were able to identify 2 new sources, 3 new models, 3 new tests.
From inspection of these changes, it was identified that the source of the issue was misspellings in the new schema.yml files as follows:
Which are misspelled invocations of a built in test, and 2 common yml keys. dbt Core should be able to surface misspellings like this more obviously to the end user
Expected Behavior
Helpful error messaging is surfaced to the end user when there are misspelling keys in the yml file
Steps To Reproduce
Misspell a key in a schema.yml file such as:
save changes and do a 'dbt run'
observe the opaque error messaging available
Relevant log output
No response
Environment
What database are you using dbt with?
bigquery
Additional Context
No response