-
Notifications
You must be signed in to change notification settings - Fork 15.9k
Fix Connection or Variable access in Server context #56602
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
Conversation
Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with `ImportError` for `SUPERVISOR_COMMS` because it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval. Implemented automatic context detection using separate secrets backend chains for client and server processes: - Client contexts (workers, DAG processors, triggerers) are detected via `SUPERVISOR_COMMS` presence and use `ExecutionAPISecretsBackend` to route through the Execution API - Server contexts (API server, scheduler, plugins) are detected when `SUPERVISOR_COMMS` is unavailable and use `MetastoreBackend` for direct database access Fixes apache#56120 Fixes apache#56583
8d21aaf to
0cfdaa5
Compare
0cfdaa5 to
ade61f4
Compare
jason810496
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix!
ashb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Messier then i'd like but i can't think of another option right now
Thanks @gopidesupavan , Please do let us know what you find! |
just in time: works fine with this changes :)
|
Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with `ImportError` for `SUPERVISOR_COMMS` because it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval. Implemented automatic context detection using separate secrets backend chains for client and server processes: - Client contexts (workers, DAG processors, triggerers) are detected via `SUPERVISOR_COMMS` presence and use `ExecutionAPISecretsBackend` to route through the Execution API - Server contexts (API server, scheduler, plugins) are detected when `SUPERVISOR_COMMS` is unavailable and use `MetastoreBackend` for direct database access Fixes #56120 Fixes #56583 (cherry picked from commit ae0a330)
Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with `ImportError` for `SUPERVISOR_COMMS` because it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval. Implemented automatic context detection using separate secrets backend chains for client and server processes: - Client contexts (workers, DAG processors, triggerers) are detected via `SUPERVISOR_COMMS` presence and use `ExecutionAPISecretsBackend` to route through the Execution API - Server contexts (API server, scheduler, plugins) are detected when `SUPERVISOR_COMMS` is unavailable and use `MetastoreBackend` for direct database access Fixes apache#56120 Fixes apache#56583
Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with `ImportError` for `SUPERVISOR_COMMS` because it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval. Implemented automatic context detection using separate secrets backend chains for client and server processes: - Client contexts (workers, DAG processors, triggerers) are detected via `SUPERVISOR_COMMS` presence and use `ExecutionAPISecretsBackend` to route through the Execution API - Server contexts (API server, scheduler, plugins) are detected when `SUPERVISOR_COMMS` is unavailable and use `MetastoreBackend` for direct database access Fixes apache#56120 Fixes apache#56583
Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with `ImportError` for `SUPERVISOR_COMMS` because it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval. Implemented automatic context detection using separate secrets backend chains for client and server processes: - Client contexts (workers, DAG processors, triggerers) are detected via `SUPERVISOR_COMMS` presence and use `ExecutionAPISecretsBackend` to route through the Execution API - Server contexts (API server, scheduler, plugins) are detected when `SUPERVISOR_COMMS` is unavailable and use `MetastoreBackend` for direct database access Fixes apache#56120 Fixes apache#56583
Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with `ImportError` for `SUPERVISOR_COMMS` because it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval. Implemented automatic context detection using separate secrets backend chains for client and server processes: - Client contexts (workers, DAG processors, triggerers) are detected via `SUPERVISOR_COMMS` presence and use `ExecutionAPISecretsBackend` to route through the Execution API - Server contexts (API server, scheduler, plugins) are detected when `SUPERVISOR_COMMS` is unavailable and use `MetastoreBackend` for direct database access Fixes apache#56120 Fixes apache#56583
When deferrable operators run in the triggerer's async event loop and synchronously access connections (e.g., via @cached_property), the `ExecutionAPISecretsBackend` failed silently. This occurred because `SUPERVISOR_COMMS.send()` uses `async_to_sync`, which raises `RuntimeError` when called within an existing event loop in a greenback portal context. Add specific RuntimeError handling in `ExecutionAPISecretsBackend` that detects this scenario and uses `greenback.await_()` to call the async versions (aget_connection/aget_variable) as a fallback. It was originally fixed in apache#55799 for 3.1.0 but apache#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache#55568 Fixes apache#57145
When deferrable operators run in the triggerer's async event loop and synchronously access connections (e.g., via @cached_property), the `ExecutionAPISecretsBackend` failed silently. This occurred because `SUPERVISOR_COMMS.send()` uses `async_to_sync`, which raises `RuntimeError` when called within an existing event loop in a greenback portal context. Add specific RuntimeError handling in `ExecutionAPISecretsBackend` that detects this scenario and uses `greenback.await_()` to call the async versions (aget_connection/aget_variable) as a fallback. It was originally fixed in apache#55799 for 3.1.0 but apache#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache#55568 Fixes apache#57145
When deferrable operators run in the triggerer's async event loop and synchronously access connections (e.g., via @cached_property), the `ExecutionAPISecretsBackend` failed silently. This occurred because `SUPERVISOR_COMMS.send()` uses `async_to_sync`, which raises `RuntimeError` when called within an existing event loop in a greenback portal context. Add specific RuntimeError handling in `ExecutionAPISecretsBackend` that detects this scenario and uses `greenback.await_()` to call the async versions (aget_connection/aget_variable) as a fallback. It was originally fixed in apache#55799 for 3.1.0 but apache#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache#55568 Fixes apache#57145
When deferrable operators run in the triggerer's async event loop and synchronously access connections (e.g., via @cached_property), the `ExecutionAPISecretsBackend` failed silently. This occurred because `SUPERVISOR_COMMS.send()` uses `async_to_sync`, which raises `RuntimeError` when called within an existing event loop in a greenback portal context. Add specific RuntimeError handling in `ExecutionAPISecretsBackend` that detects this scenario and uses `greenback.await_()` to call the async versions (aget_connection/aget_variable) as a fallback. It was originally fixed in apache#55799 for 3.1.0 but apache#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache#55568 Fixes apache#57145
When deferrable operators run in the triggerer's async event loop and synchronously access connections (e.g., via @cached_property), the `ExecutionAPISecretsBackend` failed silently. This occurred because `SUPERVISOR_COMMS.send()` uses `async_to_sync`, which raises `RuntimeError` when called within an existing event loop in a greenback portal context. Add specific RuntimeError handling in `ExecutionAPISecretsBackend` that detects this scenario and uses `greenback.await_()` to call the async versions (aget_connection/aget_variable) as a fallback. It was originally fixed in #55799 for 3.1.0 but #56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: #55568 Fixes #57145
When deferrable operators run in the triggerer's async event loop and synchronously access connections (e.g., via @cached_property), the `ExecutionAPISecretsBackend` failed silently. This occurred because `SUPERVISOR_COMMS.send()` uses `async_to_sync`, which raises `RuntimeError` when called within an existing event loop in a greenback portal context. Add specific RuntimeError handling in `ExecutionAPISecretsBackend` that detects this scenario and uses `greenback.await_()` to call the async versions (aget_connection/aget_variable) as a fallback. It was originally fixed in #55799 for 3.1.0 but #56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: #55568 Fixes #57145 (cherry picked from commit da32b68)


Hooks used in API server contexts (plugins, middlewares, log handlers) previously failed with
ImportErrorforSUPERVISOR_COMMSbecause it only exists in worker Task execution contexts (Worker, Dag processor, Trigger). This prevented using hooks like GCSHook or S3Hook in plugins and broke log retrieval.Implemented automatic context detection using separate secrets backend chains for client and server processes:
SUPERVISOR_COMMSpresence and useExecutionAPISecretsBackendto route through the Execution APISUPERVISOR_COMMSis unavailable and useMetastoreBackendfor direct database accessFixes #56120
Fixes #56583
PS: I do not love the way we deal with secrets backends in airflow/configuration, even before this PR -- but not going to handle it in this PR.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.