Uh oh!
There was an error while loading. Please reload this page.
Fix Connection or Variable access in Server context - #56602
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 Fixesapache#56120Fixesapache#56583
8d21aaf to
0cfdaa5Compare0cfdaa5 to
ade61f4CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ashb
left a comment
There was a problem hiding this comment.
Messier then i'd like but i can't think of another option right now
Uh oh!
There was an error while loading. Please reload this page.
gopidesupavan
commented
Oct 14, 2025
Uh oh!
There was an error while loading. Please reload this page.
kaxil
commented
Oct 14, 2025
Thanks @gopidesupavan , Please do let us know what you find! |
gopidesupavan
commented
Oct 14, 2025
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#56120Fixes#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 Fixesapache#56120Fixesapache#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#55568Fixesapache#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#55568Fixesapache#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#55568Fixesapache#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#55568Fixesapache#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: #55568Fixes#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: #55568Fixes#57145 (cherry picked from commit da32b68)
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/airflow#55799 for 3.1.0 but apache/airflow#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache/airflow#55568Fixesapache/airflow#57145 (cherry picked from commit da32b682d1b0df5d5e2078392cf8626f8fdb00ff) GitOrigin-RevId: f969e6374daa8469938169be16a28f7c073a5ce9
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/airflow#55799 for 3.1.0 but apache/airflow#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache/airflow#55568Fixesapache/airflow#57145 GitOrigin-RevId: da32b682d1b0df5d5e2078392cf8626f8fdb00ff
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/airflow#55799 for 3.1.0 but apache/airflow#56602 introduced a bug. Ideally all providers handle this better and have better written Triggers. Example PR for Databricks: apache/airflow#55568Fixesapache/airflow#57145 (cherry picked from commit da32b682d1b0df5d5e2078392cf8626f8fdb00ff) GitOrigin-RevId: f969e6374daa8469938169be16a28f7c073a5ce9


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.