Skip to content

fix(hfs): drain on SIGTERM as well as Ctrl-C (Phase 0.3) - #907

Open
aacruzgon wants to merge 1 commit into
mainfrom
cluster/p0.3-sigterm
Open

fix(hfs): drain on SIGTERM as well as Ctrl-C (Phase 0.3)#907
aacruzgon wants to merge 1 commit into
mainfrom
cluster/p0.3-sigterm

Conversation

@aacruzgon

Copy link
Copy Markdown
Contributor

Summary

Phase 0.3 of the cluster-capable-state rebuild (discussion #223). hfs only ever drained on Ctrl-C; a SIGTERM from a process supervisor, container runtime, or a load balancer's rolling deploy killed it outright after the grace period, with requests in flight and the audit sink unflushed. The graceful-shutdown future now resolves on either signal and logs which one fired.

Independent of #905 and #906 (branched from main; touches only serve()'s shutdown future).

Changes

  • crates/hfs/src/main.rs — new shutdown_signal() that select!s over tokio::signal::ctrl_c() and, on Unix, SignalKind::terminate(); serve()'s with_graceful_shutdown uses it and logs signal="SIGINT"|"SIGTERM". The audit flush and OTLP flush that follow are unchanged. If the SIGTERM handler cannot be installed the server warns and keeps Ctrl-C only. Non-Unix builds keep Ctrl-C only. tokio's full feature already includes signal, so no manifest change.

Testing

  • Local: started hfs (sqlite, in-memory), confirmed /health 200, sent kill -TERM; the process logged Shutdown signal received, draining connections signal="SIGTERM" and exited within a second. Without this change the same signal terminates the process with no drain and no log line.
  • cargo test -p helios-hfs --no-default-features --features R4,sqlite,postgres — 8 passed (no unit test can send a signal; the T3 cluster-smoke stop step switches to kill -TERM in PR 0.4 and asserts a clean exit).
  • cargo fmt --all; CI-exact clippy clean.

Notes

  • hts, sof-server, and fhirpath-server have no graceful shutdown at all (bare axum::serve); noted as a follow-up, same ~25 lines each.

The graceful-shutdown future only waited on Ctrl-C, so a SIGTERM from a
process supervisor, container runtime, or a load balancer's rolling deploy
killed the server after the grace period with requests in flight and the
audit sink unflushed — the normal way an instance in a cluster is stopped.

`serve()` now waits on a `shutdown_signal()` that selects over Ctrl-C and,
on Unix, SIGTERM, and logs which signal fired; the drain, audit flush and
OTLP flush that follow are unchanged. A failed SIGTERM handler install
warns and keeps Ctrl-C only; non-Unix builds keep Ctrl-C only.

Tests: verified by hand — a running instance answers /health, receives
`kill -TERM`, logs `Shutdown signal received … signal="SIGTERM"` and exits
within a second. The two-instance smoke's stop step switches to SIGTERM in
the next cluster PR so this stays covered in CI.
@codecov

codecov Bot commented Sep 2, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant