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

Failure in test not_null_fct_dbt__latest_full_model_executions_node_id #75

Closed
alanmcruickshank opened this issue Jan 31, 2022 · 4 comments · Fixed by #77
Closed

Failure in test not_null_fct_dbt__latest_full_model_executions_node_id #75

alanmcruickshank opened this issue Jan 31, 2022 · 4 comments · Fixed by #77

Comments

@alanmcruickshank
Copy link
Contributor

We're intermittently experiencing this failure:

Failure in test not_null_fct_dbt__latest_full_model_executions_node_id (models/schemas.yml)
  Got 1 result, configured to fail if != 0

  compiled SQL at target/compiled/dbt_artifacts/models/schemas.yml/schema_test/not_null_fct_dbt__latest_full_model_executions_node_id.sql

On inspection this happens when a new upload coincides with an incremental run of the package. Due to (what I'm pretty sure is...) a race condition means that while the most recent run is present in fct_dbt__run_results, it is not present in fct_dbt__model_executions - and so the most recent run appears to have no model executions. The current workaround is to run a full rebuild, which take significant time.

A better solution would be to only allow runs which have model executions in this model. It adds complexity but would explicitly eliminate this race condition.

@NiallRees
Copy link
Contributor

I actually think this one might have been resolved by dd5e64f. Would you be able to check?

@alanmcruickshank
Copy link
Contributor Author

I've linked to a separate issue which would solve this bug in a slightly different way by changing the intent of the model. If we don't want to take that route - then the more direct solutions are the ones above.

@alanmcruickshank
Copy link
Contributor Author

alanmcruickshank commented Jan 31, 2022

I actually think this one might have been resolved by dd5e64f. Would you be able to check?

I haven't checked by updating the package, but I've run that query with the new code and the problem is still there.

The issue in my case isn't the type of the run, it's the race condition which means the run exists before it's model runs do.

@alanmcruickshank
Copy link
Contributor Author

As per conversation in #76 - I'm going to assume we don't fix this directly, but instead fix it by doing what I've suggested there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants