-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
[CT-1233] [Bug] Race condition in lib.py causes concurrent API calls to fail #5919
Comments
Thanks for opening @drewbanin! I think you have a short-term patch for this, which feels appropriate for now. @iknox-fa and I have been chatting about this a bit, most recently over in #5533. De-globalizing adapters, while not in the immediate scope of API-ification, is something I'd like to tackle in the next few months. I think we can disambiguate between:
Aside from registering/clearing adapters, there are two other pieces of global state mutation in
Those are both things we'll want to "de-globalize," in addition to adapters, and I sense they would be smaller lifts. |
* (#5919) Fix adapter reset race condition in lib.py * run black * changie
* (#5919) Fix adapter reset race condition in lib.py * run black * changie (cherry picked from commit 4e8aa00) Co-authored-by: Drew Banin <[email protected]>
Is this a new bug in dbt-core?
Current Behavior
The
lib.py
file in Core contains logic to "reset adapters" in the process of generating a RuntimeConfig object. While this logic is appropriate for single-threaded usage of dbt Core, we've seen that concurrent api calls to this method can result in race conditions:dbt-core/core/dbt/lib.py
Lines 27 to 32 in 5678344
The
reset_adapters
call will clear out the set of adapters registered in the dbt Core adapter factory. If a concurrent api call accesses adapters (eg. to compile sql, or run dbt, or similar) before theregister_adapters
call is complete, there's a chance it will fail with aKeyError
eg. here because the adapter dictionary was cleared in another thread.Expected Behavior
The
get_dbt_config
should not mutate global state to generate a RuntimeConfig.Steps To Reproduce
Here's a minimal repro case:
Relevant log output
No response
Environment
Which database adapter are you using with dbt?
postgres, redshift, snowflake, bigquery, spark
Additional Context
I am interested in submitting a patch for this issue
The text was updated successfully, but these errors were encountered: