The GitHub Actions job "Tests (AMD)" on airflow.git/fix/cloudwatch/remote-logging-k8s-executor has failed. Run started by GitHub user jason810496 (triggered by jason810496).
Head commit for run: a92793f39262ff752b850046d45346e9bd195635 / LIU ZHE YOU <[email protected]> Scope CloudWatch handler rebuild to dictConfig closures only The streaming CloudWatch handler is rebuilt whenever it reports shutting_down, so logs survive configure_logging() closing it. But shutting_down alone cannot tell a mid-task close apart from genuine teardown, so a record arriving after teardown would spin up an orphan handler and its background queue thread that nobody flushes or closes. The supervisor lifecycle makes the two cases distinguishable in time: 1. configure_logging() builds the handler via remote.processors (processors does `_ = self.handler`), registering it in logging._handlerList. 2. The same call then runs dictConfig, whose non-incremental reset closes that handler -> watchtower sets shutting_down=True. 3. Child log records stream through proc -> self.handler, which sees shutting_down and rebuilds. This is the case we must keep working. 4. At the last possible moment _upload_logs() -> upload() -> close() flushes; nothing logs after this. shutting_down is watchtower's flag set by dictConfig (step 2); the new _closed flag is ours, set only by close() (step 4). dictConfig never touches _closed, so the rebuild in step 3 still fires, while a late record after step 4 keeps the closed handler instead of orphaning a new one. close() on the outer CloudwatchTaskHandler now closes the handler the IO is currently using rather than the reference captured in set_context(), which dictConfig may have closed and the IO since rebuilt. Report URL: https://github.com/apache/airflow/actions/runs/27861530233 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
