Closed alanmcruickshank closed 2 years ago
I actually think this one might have been resolved by https://github.com/brooklyn-data/dbt_artifacts/commit/dd5e64fe28270fbb1634ca85e41a922a8c37c742. Would you be able to check?
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.
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.
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.
We're intermittently experiencing this failure:
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 infct_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.