fix(container): handle SIGTERM - node is PID 1 and was ignoring it (#120)

[wormeyman]

#120 measured the container staying awake ~8.5 minutes against a configured sleepAfter = "20s", and reasoned the likely cause was scheduling granularity in @cloudflare/containers' alarm loop - explicitly flagged UNVERIFIED, with a note that someone should trace it rather than infer it from a comment.

Tracing it says otherwise. The root cause is in this repo.

The alarm clamp is not it

minTime starts at Date.now() + 3 * 60 * 1000 and sleepAfterMs is also an absolute timestamp, so

minTime = Math.min(minTimeFromSchedules, minTime, this.sleepAfterMs);

picks the earlier of them - a 20s sleepAfter wins over the 3m ceiling. And on expiry the loop calls onActivityExpired() then renewActivityTimeout(), i.e. it re-checks every 20s. There is no minutes-long floor there.

What the trace does show

At the SDK's own sleepAfter declaration:

// The signal sent to the container by default is a SIGTERM.
// The container won't get a SIGKILL if this threshold is triggered.
sleepAfter = DEFAULT_SLEEP_AFTER;

onActivityExpired() calls stop(), which sends SIGTERM and never escalates.

And our Dockerfile is ENTRYPOINT ["node", "/app/server.mjs"] - exec form, no shell, no init - so node runs as PID 1. Linux gives PID 1 no default signal dispositions, and server.mjs registered no handler, so the SIGTERM was silently discarded. The SDK therefore never stopped the container at all; it lingered until the platform reclaimed it. That is the ~8.5 minute tail.

The fix

Handle SIGTERM (and SIGINT), server.close() then exit(0). Closing rather than exiting outright lets an in-flight render finish streaming - which matters because the Worker must drain the response body for its own inflight counter to decrement (the sleepAfter note in CLAUDE.md).

The test, and what it cannot prove

test/shutdown.test.mjs spawns the real server and sends it a real SIGTERM. Its limits are stated in the file rather than overclaimed:

• The spawned child is not pid 1, so it keeps the default disposition and dies on SIGTERM even with no handler. Deleting the handler makes the test fail on the exit-code assertion (code: null, signal: SIGTERM instead of a clean exit(0)) in ~34ms - not by timing out. Verified by planting that removal.
• The timeout arm covers the genuine pid-1 case, which no harness outside a container can reproduce. It is kept because a handler that hangs instead of exiting would be caught by nothing else.

PORT becomes overridable (default still 8080) so the test can bind a free port.

Not yet confirmed in production

This is a code-level root cause, not a measured fix. Confirming it means deploying and re-reading the containersUsageAdaptiveGroups buckets for a single render. The issue's step 2 - setting sleepAfter to "10m" to test whether the value is inert - becomes unnecessary if this is right, and stays the fallback if the tail survives.

I have not deployed; that is your call, and the issue notes the current cost is ~$0.12/month so there is no urgency.

Verification

pnpm run verify green - 1588 app + 13 worker + 4 container (up 1), 0 warnings, exit 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HKjzpWJw1HbnigPP9udqN2