hermes-agent/tests/gateway/test_cron_active_work_drain.py
joaomarcos 24e9ed73c2 fix(gateway,cron): make shutdown drain visible to in-flight cron work
Cron jobs run through cron/scheduler.py's own ThreadPoolExecutor via a
standalone AIAgent (run_job/run_one_job), entirely outside
GatewayRunner._running_agents -- the dict _drain_active_agents() and
every other active-work check on that class reads. A gateway shutdown
(/update, /restart, and SIGUSR1 all funnel through the same stop())
could log active_at_start=0 and immediately kill tool subprocesses
while a cron job's terminal command was still running, with no wait
and no indication anything was interrupted.

Real-world impact (from the issue): a scheduled daily briefing cron
job was in flight during /update, its tool subprocess got killed
by the unconditional shutdown cleanup, and the job was never marked
failed -- it simply never completed or delivered, with no error
surfaced anywhere. A repro with a 30-minute `sleep` cron job in flight
during /update reproduced the same pattern: subprocess killed at
+0.22s of drain (active_at_start=0), the job's agent thread continued
in-process and produced a plausible-looking final response from the
truncated tool output, and the scheduler marked the run successful.

Root cause is layered, not a single line:

1. GatewayRunner._drain_active_agents() only waits on _running_agents.
   Cron work was invisible to it, so drain returned instantly whenever
   the only active work was a cron job.
2. Even with visibility, the shutdown's final tool-subprocess kill
   (process_registry.kill_all()) is a global, unconditional sweep with
   no per-job targeting -- a long-running cron job that outlives the
   drain timeout still gets its subprocess killed.
3. cron/scheduler.py had no way to detect that a job's tool subprocess
   was killed out from under it mid-run; the agent thread kept going
   and its eventual (often degraded but plausible-looking) response
   got reported as a normal successful completion.

Fix, three parts:

- cron/scheduler.py: expose get_running_job_ids() (thread-safe
  snapshot of the existing _running_job_ids set, already used to
  prevent double-dispatch) so the gateway can read cron's in-flight
  state without reaching into private module internals.

- gateway/run.py: GatewayRunner._active_cron_job_count() reads that
  snapshot. _drain_active_agents() now waits on
  (_running_agents OR active cron jobs), so a cron-only workload gets
  the same bounded wait chat sessions already get instead of an
  instant active_at_start=0. Shutdown drain logging gains
  cron_active_at_start/cron_active_now fields alongside the existing
  ones (unchanged, for compat).

- cron/scheduler.py: mark_running_jobs_interrupted(reason), called by
  gateway/run.py's _kill_tool_subprocesses() right after
  process_registry.kill_all(), marks every job still in
  _running_job_ids at that instant as failed/interrupted via the
  existing mark_job_run() -- and records the job IDs in
  _interrupted_job_ids BEFORE writing, so run_one_job()'s own
  eventual completion for the same run (racing in its own thread)
  checks that flag and skips its normal write instead of clobbering
  the interrupted status with a false "ok" produced from the
  now-truncated tool output. This does not attempt to correlate a
  killed PID to a specific job ID (process_registry tracks PIDs, not
  job IDs) -- any job still dispatched at the moment of a forced kill
  is treated as interrupted, matching the existing coarser precedent
  set by _interrupt_running_agents(), which interrupts every entry in
  _running_agents on a drain timeout without per-agent correlation
  either.

Deliberately out of scope (flagged in the issue as a separate,
lower-priority concern): startup-time reconciliation of cron runs that
started but never reached a terminal status.

Testing:

- tests/cron/test_shutdown_interrupt.py (12 tests): get_running_job_ids
  snapshot semantics, mark_running_jobs_interrupted marking/no-op/
  partial-failure behavior, and -- the core race guard -- run_one_job
  skipping its own last_status write (both the success path and the
  exception path) when the shutdown path already marked the run
  interrupted, with a control test proving ordinary un-interrupted
  completions are unaffected.

- tests/gateway/test_cron_active_work_drain.py (9 tests):
  _active_cron_job_count reading cron state and failing closed (0) if
  the cron module is unavailable; _drain_active_agents waiting for an
  in-flight cron job the same way it waits for chat sessions, timing
  out if the job outruns the window, and leaving existing chat-session
  drain behavior unchanged; a full runner.stop() integration test
  (drain-timeout path) proving mark_running_jobs_interrupted actually
  fires with the right job ID when a tool subprocess is force-killed,
  plus a no-op control when nothing cron-related is in flight.

- tests/gateway/test_shutdown_cache_cleanup.py: added
  _active_cron_job_count() to that file's hand-rolled _FakeGateway test
  double, which stop() now calls -- without it those 8 pre-existing
  tests AttributeError (caught by fail-then-pass below, not a
  production bug).

Fail-then-pass: reverted gateway/run.py + cron/scheduler.py, all 21
new tests fail (fixture/attribute errors -- the feature doesn't exist
yet); restored, all 21 pass.

Regression check: ran the full plausibly-affected surface --
tests/gateway/{test_gateway_shutdown,test_restart_drain,
test_restart_notification,test_restart_redelivery_dedup,
test_restart_resume_pending,test_restart_service_detection,
test_shutdown_cache_cleanup,test_stuck_loop,test_clean_shutdown_marker,
test_external_drain_control,test_session_state_cleanup,
test_update_command,test_update_streaming}.py plus tests/cron/ (944
tests) -- against a clean upstream/main checkout and against this
branch. Diffed the two FAILED lists: identical, 20 pre-existing
failures on both sides (Windows-locale/cp1252 file-encoding issues and
Unix-permission-bit assertions that don't apply on this Windows dev
box), zero new failures, zero fixed-by-accident. The 8
test_shutdown_cache_cleanup.py failures found mid-development were
from the _FakeGateway gap above, fixed in the same commit and
confirmed clean on the final rerun (diff against baseline: exit 0).

Fixes #60432
2026-07-07 22:15:04 -07:00

185 lines
6.6 KiB
Python

"""Tests for #60432: the gateway shutdown drain was structurally blind to
in-flight cron work. Cron jobs run through cron/scheduler.py's own thread
pool, entirely outside ``GatewayRunner._running_agents`` -- the dict every
other active-work check on this class reads. A shutdown (``/update``,
``/restart``, SIGUSR1 -- they all funnel through the same ``stop()``) could
report ``active_at_start=0`` and immediately kill tool subprocesses while a
cron job's terminal command was still running.
These tests cover the gateway side of the fix:
- _active_cron_job_count() reads cron.scheduler's in-flight job set
- _drain_active_agents() waits for cron work the same way it already
waits for chat sessions
- the final tool-subprocess kill marks any still-in-flight cron job
interrupted
See tests/cron/test_shutdown_interrupt.py for the cron-side primitives
this relies on (get_running_job_ids, mark_running_jobs_interrupted).
"""
import asyncio
from unittest.mock import MagicMock, patch
import pytest
from tests.gateway.restart_test_helpers import make_restart_runner
@pytest.fixture(autouse=True)
def _reset_cron_running_set():
import cron.scheduler as sched
sched._running_job_ids.clear()
sched._interrupted_job_ids.clear()
yield
sched._running_job_ids.clear()
sched._interrupted_job_ids.clear()
def _make_async_noop():
async def _noop(*args, **kwargs):
return None
return _noop
class TestActiveCronJobCount:
def test_zero_when_no_cron_jobs_running(self):
runner, _adapter = make_restart_runner()
assert runner._active_cron_job_count() == 0
def test_reflects_cron_scheduler_state(self):
import cron.scheduler as sched
runner, _adapter = make_restart_runner()
sched._running_job_ids.add("job-1")
assert runner._active_cron_job_count() == 1
def test_never_raises_if_cron_module_unavailable(self):
"""Best-effort: a broken/absent import must not take shutdown
counting down with it."""
runner, _adapter = make_restart_runner()
with patch(
"cron.scheduler.get_running_job_ids", side_effect=ImportError("boom")
):
assert runner._active_cron_job_count() == 0
class TestDrainWaitsForCronWork:
@pytest.mark.asyncio
async def test_drain_returns_immediately_when_nothing_active(self):
runner, _adapter = make_restart_runner()
_snapshot, timed_out = await runner._drain_active_agents(5.0)
assert timed_out is False
@pytest.mark.asyncio
async def test_drain_waits_for_in_flight_cron_job(self):
"""Before this fix, a cron-only workload made active_at_start=0
and the drain returned instantly -- this is the exact repro from
the issue (a `sleep 1800` cron job in flight during /update)."""
import cron.scheduler as sched
runner, _adapter = make_restart_runner()
sched._running_job_ids.add("job-1")
async def finish_job():
await asyncio.sleep(0.12)
sched._running_job_ids.discard("job-1")
task = asyncio.create_task(finish_job())
_snapshot, timed_out = await runner._drain_active_agents(2.0)
await task
assert timed_out is False, (
"drain must wait for the cron job to finish, not report "
"active_at_start=0 and return instantly"
)
@pytest.mark.asyncio
async def test_drain_times_out_if_cron_job_outlives_the_window(self):
import cron.scheduler as sched
runner, _adapter = make_restart_runner()
sched._running_job_ids.add("job-1") # never removed within the window
_snapshot, timed_out = await runner._drain_active_agents(0.1)
assert timed_out is True
@pytest.mark.asyncio
async def test_drain_still_waits_for_chat_sessions_unchanged(self):
"""Regression guard: folding cron into the check must not break
the pre-existing chat-session drain behavior."""
runner, _adapter = make_restart_runner()
runner._running_agents = {"session-1": MagicMock()}
async def finish_agent():
await asyncio.sleep(0.12)
runner._running_agents.clear()
task = asyncio.create_task(finish_agent())
_snapshot, timed_out = await runner._drain_active_agents(2.0)
await task
assert timed_out is False
class TestKillToolSubprocessesMarksCronInterrupted:
@pytest.mark.asyncio
async def test_in_flight_cron_job_marked_interrupted_on_forced_kill(self, monkeypatch):
import cron.scheduler as sched
import tools.process_registry as _pr
import tools.terminal_tool as _tt
import tools.browser_tool as _bt
runner, adapter = make_restart_runner()
runner._restart_drain_timeout = 0.01 # force the timeout path
adapter.disconnect = _make_async_noop()
sched._running_job_ids.add("job-1")
monkeypatch.setattr(_pr.process_registry, "kill_all", lambda task_id=None: 1)
monkeypatch.setattr(_tt, "cleanup_all_environments", lambda: None)
monkeypatch.setattr(_bt, "cleanup_all_browsers", lambda: None)
marked_calls = []
real_mark = sched.mark_running_jobs_interrupted
def _spy(reason):
result = real_mark(reason)
marked_calls.append((reason, result))
return result
monkeypatch.setattr(sched, "mark_running_jobs_interrupted", _spy)
with patch("gateway.status.remove_pid_file"), patch("gateway.status.write_runtime_status"), \
patch("cron.scheduler.mark_job_run"):
await runner.stop()
assert marked_calls, "mark_running_jobs_interrupted was never called during shutdown"
assert any(result == ["job-1"] for _reason, result in marked_calls)
@pytest.mark.asyncio
async def test_no_cron_jobs_running_is_a_silent_no_op(self, monkeypatch):
"""Graceful shutdown with nothing in flight must not spuriously
mark or log anything cron-related."""
import tools.process_registry as _pr
import tools.terminal_tool as _tt
import tools.browser_tool as _bt
runner, adapter = make_restart_runner()
adapter.disconnect = _make_async_noop()
monkeypatch.setattr(_pr.process_registry, "kill_all", lambda task_id=None: 0)
monkeypatch.setattr(_tt, "cleanup_all_environments", lambda: None)
monkeypatch.setattr(_bt, "cleanup_all_browsers", lambda: None)
with patch("gateway.status.remove_pid_file"), patch("gateway.status.write_runtime_status"), \
patch("cron.scheduler.mark_job_run") as mock_mark:
await runner.stop()
mock_mark.assert_not_called()