JoelEmmanuelCloud opened a new pull request, #76410: URL: https://github.com/apache/airflow/pull/76410
## What this is Scaffolding for per-executor health reporting, discussed on the dev list: "[DISCUSS] Per-executor health reporting via /api/v2/monitor/health". This is **not** a working health check for any executor. It's the plumbing a concrete executor needs to report health through, consistent with what came out of discussion with Vincent Beck and Dennis Ferruzzi: - `BaseExecutor.get_health() -> bool | None` — new override point. Default returns `None`, so every existing executor's behaviour is unchanged. - - `SchedulerJobRunner` polls each executor's `get_health()` on its own timer (`[scheduler] executor_health_check_interval`, default 30s). Each check runs in its own worker thread with an in-flight guard, so a slow or hung backend can delay only that executor's own health visibility, never the scheduler loop. - - A successful check is recorded as a `Job` row (`job_type="ExecutorJob"`), reusing the existing Jobs table and `JobState` values rather than a new status model, exactly like Scheduler/Triggerer/DagProcessor already do. - - `/monitor/health` gains a top-level `executor` entry, a sibling of `scheduler`/`triggerer`/`dag_processor`, not nested under any of them, per the preference expressed on the list. - - It's included only once a configured executor actually implements `get_health()`; until then it's omitted from the response entirely, not reported as a false "unhealthy" for a feature nothing has adopted yet. Since nothing overrides `get_health()` in this PR, the change is inert by itself. A CeleryExecutor implementation (the PoC discussed on the list) is the planned follow-up PR. ## Why draft Posting this now, while the dev-list thread is still open, so the actual code is available to look at alongside the discussion rather than only after it settles. ## Related - dev-list thread: [DISCUSS] Per-executor health reporting via /api/v2/monitor/health -- 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]
