jason810496 commented on PR #75184: URL: https://github.com/apache/airflow/pull/75184#issuecomment-6306874722
> Having a whole separate process to handle xcom uplodads feels overkill. Why can't we do it from the coordinator process directly? The "why" in the PR desc doesn't address this Good point, I've added this to the Why in the description: 1. **Fork safety.** The supervisor runs inside the long-lived worker process (for example the Celery worker child), which also forks the Python task processes. A backend run there leaves its state in that process: `XComObjectStorageBackend` caches its fsspec filesystem (`_STORE_CACHE` in `airflow.sdk.io.store`), and a Python task forked from that process later fails with `RuntimeError: This class is not fork-safe`. 2. **The supervisor stays in control.** A backend call blocks on I/O. In the supervisor, a hung upload would block the loop that heartbeats and enforces `execution_timeout`, with no way to interrupt it. In a separate process, the supervisor keeps heartbeating during the call, and kills the helper on `execution_timeout`, when the server stops the task, or after too many failed heartbeats. The helper is also lazy and per task: it starts on the first call the configured backend handles and serves all of that task's XCom calls, so tasks on the default `BaseXCom` never start it. It is also not meant for XCom only. Any worker-side backend that runs in a Python task's process and keeps in-memory state should run in this helper for the same isolation, so the `[workers] state_store_backend` and the worker's secrets backends are next. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
