You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PR #126 added --foreground for running extenddb serve under a process supervisor. The supervisor scenario relies on graceful SIGTERM shutdown: the process must drain in-flight connections, remove its PID file, and exit non-zero only on actual failure.
Today, this is verified manually (the PR description shows kill -TERM against a foreground process), but there's no automated coverage. A regression in the signal-handling path would not be caught by CI.
The reviewer on #126 explicitly suggested cutting this as a follow-up because the current test framework is not yet set up for whole-process lifecycle tests, so the work likely involves harness changes too.
Proposed solution
Add a Python integration test (or rust integration test under tests/) that:
Spawns extenddb serve --foreground as a subprocess with stdout/stderr piped.
Waits for the listener to come up (poll /health until 200, with a timeout).
Optionally drives a PutItem through the AWS SDK to confirm a real request path is open.
Sends SIGTERM to the child.
Asserts the process exits with status 0 within a graceful-shutdown deadline (e.g., 10s).
Asserts the PID file at ~/.extenddb/run/extenddb-<port>.pid was removed.
Asserts stderr contains the expected Shutdown signal received, draining connections... log line.
This will probably require small additions to the test harness:
A way to launch extenddb with isolated ~/.extenddb/ (e.g., via HOME override or a --run-dir option).
A way to grep child stderr without racing the test runner.
Problem or use case
PR #126 added
--foregroundfor runningextenddb serveunder a process supervisor. The supervisor scenario relies on graceful SIGTERM shutdown: the process must drain in-flight connections, remove its PID file, and exit non-zero only on actual failure.Today, this is verified manually (the PR description shows
kill -TERMagainst a foreground process), but there's no automated coverage. A regression in the signal-handling path would not be caught by CI.The reviewer on #126 explicitly suggested cutting this as a follow-up because the current test framework is not yet set up for whole-process lifecycle tests, so the work likely involves harness changes too.
Proposed solution
Add a Python integration test (or rust integration test under
tests/) that:extenddb serve --foregroundas a subprocess with stdout/stderr piped./healthuntil 200, with a timeout).PutItemthrough the AWS SDK to confirm a real request path is open.SIGTERMto the child.~/.extenddb/run/extenddb-<port>.pidwas removed.Shutdown signal received, draining connections...log line.This will probably require small additions to the test harness:
extenddbwith isolated~/.extenddb/(e.g., viaHOMEoverride or a--run-diroption).Context
servecommand #126 review comment bypdf-amzn, item 3.crates/bin/src/cmd_serve.rs::run(skips daemonize block) andcrates/server/src/lib.rs::start_server(existing graceful-shutdown handler).Checklist