Skip to content

Fix in-process Execution API loop stopped while transport still in use - #68865

Merged
o-nikolas merged 2 commits into
apache:mainfrom
aws-mwaa:fix-inprocess-api-loop-lifecycle
Jun 23, 2026
Merged

Fix in-process Execution API loop stopped while transport still in use#68865
o-nikolas merged 2 commits into
apache:mainfrom
aws-mwaa:fix-inprocess-api-loop-lifecycle

Conversation

@seanghaeli

@seanghaeliseanghaeli commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Fix failing CIs, same as #68855 but needed fixing now (just a typo) so opening this PR

apache#68840 moved the InProcessExecutionAPI background event-loop + thread
cleanup into a weakref.finalize keyed on the InProcessExecutionAPI
instance. But callers build a sync Client from
InProcessExecutionAPI().transport and discard the factory object, so the
instance is garbage-collected while the transport is still in use. The
finalizer then stops the loop, and every subsequent request hangs on the
dead loop -- surfacing as Timeout failures across the Dag-processor and
triggerer in-process API tests on main (Error while closing in-process
execution API lifespan -> TimeoutError).
Key the finalizer on the returned WSGI transport instead of the factory
instance, so loop/thread/lifespan teardown happens when the transport
(which the Client holds) is collected, not when the throwaway factory is.
Verified locally: test_processor.py::test_top_level_variable_set and
test_top_level_variable_access_not_found now pass (previously hung to
timeout).
Rewrite test_in_process_execution_api_teardown as
test_in_process_execution_api_transport_lifecycle: assert that dropping
the factory instance leaves the loop running while the transport is held,
and only dropping the transport stops the loop + joins the daemon thread.
This fails against finalizing on the instance (the regression) and passes
with the finalizer keyed on the transport.
Verified locally: 1 passed in 11.58s.
@o-nikolas
o-nikolas merged commit ab4c097 into apache:mainJun 23, 2026
77 checks passed
@o-nikolas
o-nikolas deleted the fix-inprocess-api-loop-lifecycle branch June 23, 2026 01:33
@vatsrahul1001vatsrahul1001 added this to the Airflow 3.3.0 milestone Jun 23, 2026
cetingokhan pushed a commit to cetingokhan/airflow that referenced this pull request Jun 24, 2026
apache#68865)
* Fix in-process Execution API loop stopped while transport still in use
apache#68840 moved the InProcessExecutionAPI background event-loop + thread
cleanup into a weakref.finalize keyed on the InProcessExecutionAPI
instance. But callers build a sync Client from
InProcessExecutionAPI().transport and discard the factory object, so the
instance is garbage-collected while the transport is still in use. The
finalizer then stops the loop, and every subsequent request hangs on the
dead loop -- surfacing as Timeout failures across the Dag-processor and
triggerer in-process API tests on main (Error while closing in-process
execution API lifespan -> TimeoutError).
Key the finalizer on the returned WSGI transport instead of the factory
instance, so loop/thread/lifespan teardown happens when the transport
(which the Client holds) is collected, not when the throwaway factory is.
Verified locally: test_processor.py::test_top_level_variable_set and
test_top_level_variable_access_not_found now pass (previously hung to
timeout).
* Test transport-tied lifecycle for in-process Execution API
Rewrite test_in_process_execution_api_teardown as
test_in_process_execution_api_transport_lifecycle: assert that dropping
the factory instance leaves the loop running while the transport is held,
and only dropping the transport stops the loop + joins the daemon thread.
This fails against finalizing on the instance (the regression) and passes
with the finalizer keyed on the transport.
Verified locally: 1 passed in 11.58s.
---------
Co-authored-by: Sean Ghaeli <ghaeli@amazon.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@seanghaeli@o-nikolas@vatsrahul1001