hanxdatadog opened a new pull request, #69487:
URL: https://github.com/apache/airflow/pull/69487

   **What does this PR do?**
   - Adds an opt-in `catch_exceptions: bool = False` parameter to 
`EventScheduler.call_regular_interval`. When `True`, an exception raised by the 
periodic `action` is logged (`self.log.exception(...)`) and swallowed instead 
of propagating; the next cycle is still scheduled either way. Default is 
`False`, preserving current behavior for existing callers.
   - Enables `catch_exceptions=True` for the two `SchedulerJobRunner` periodic 
maintenance callbacks registered via `call_regular_interval` that had no 
exception handling at all: `_remove_unreferenced_triggers` and 
`_reap_stale_connection_tests`.
   
   **Motivation:**
   `EventScheduler.call_regular_interval`'s inner `repeat()` closure calls the 
registered `action` with no exception handling, so a single transient failure 
(e.g. a DB `statement_timeout` during `_remove_unreferenced_triggers`'s DELETE) 
propagates and crashes the whole `SchedulerJob`. This is inconsistent with the 
existing pattern elsewhere in `SchedulerJobRunner` — 
`_update_dag_run_state_for_paused_dags` already wraps its own body in `except 
Exception as e:  # should not fail the scheduler`, and the same crash-avoidance 
philosophy has precedent in merged PRs like #62893 (isolating per-DagRun 
failures so one bad DagRun can't crash the scheduler). `EventScheduler` is 
documented as a "general purpose" utility, so rather than making it always 
swallow exceptions (which would silently change behavior for any future caller 
that wants failures to propagate), the fix is an explicit opt-in.
   
   **Testing:**
   - Unit tests: 2 new tests in `test_event_scheduler.py` — one confirms the 
default (no flag) still propagates the action's exception, one confirms 
`catch_exceptions=True` swallows it and still schedules the next cycle.
   
   **Notes:**
   > ⚠️ Partially generated with Claude Code — all suggestions reviewed.


-- 
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]

Reply via email to