Skip to content

fix: Add configurable shutdown grace period for graceful server termination - #1103

Merged
avallete merged 3 commits into
masterfrom
claude/postgres-meta-shutdown-2crvqs
Aug 14, 2026
Merged

fix: Add configurable shutdown grace period for graceful server termination#1103
avallete merged 3 commits into
masterfrom
claude/postgres-meta-shutdown-2crvqs

Conversation

@avallete

Copy link
Copy Markdown
Member

Summary

Refactors the server shutdown logic to use a configurable grace period before force-exiting, allowing in-flight work to complete within a timeout window. This improves reliability in containerized environments where the container runtime may SIGKILL the process after its own grace period.

Key Changes

  • New environment variable: PG_META_SHUTDOWN_GRACE_PERIOD_SECS (default: 10 seconds) controls how long the server waits for in-flight work before force-exiting
  • Simplified shutdown handler: Removed complex close listener management and mutual app/adminApp hook dependencies that could cause deadlocks
  • Improved error handling: Changed to use .catch() for graceful error handling during shutdown instead of throwing, ensuring all cleanup steps attempt to run
  • Better logging: Changed signal received log from error level to info level (more appropriate for normal shutdown signals)
  • Updated documentation: Added the new environment variable to CLAUDE.md

Implementation Details

  • The closeWithGrace call now passes a delay option set to SHUTDOWN_GRACE_PERIOD_MS
  • Removed the closeListeners variable and associated hook uninstall logic that was managing listener lifecycle
  • Removed circular dependencies between app.onClose and adminApp.onClose hooks that could prevent proper shutdown
  • All cleanup operations (closing app, adminApp, destroying format pool) now use .catch() to log errors without throwing, ensuring subsequent cleanup steps execute
  • The grace period default (10s) matches Docker's default container stop grace period, with the expectation that this value should be set lower than the container runtime's grace period for the force-exit to actually execute

https://claude.ai/code/session_01Gj9ospbnecaS2ccYt2MayL

claude added 2 commits August 14, 2026 13:10
On SIGTERM the close-with-grace callback could hang past the default
10s delay - the same as Docker's default stop grace period - so the
container was routinely SIGKILLed after ~10s instead of exiting cleanly.

Two causes:

- app and adminApp each had an onClose hook closing the other, so
  app.close() could re-enter adminApp.close() (and vice versa) while it
  was already in progress and never settle. closeWithGrace already
  closes both apps, so drop the hooks.
- Each close step rethrew on failure, aborting the remaining cleanup.
  Log and continue instead so one failing step can't block the rest.

Also lower the close-with-grace delay to 1.5s so a close that still
hangs (e.g. on a stuck in-flight request) force-exits well before the
container runtime's SIGKILL.

Verified locally: clean SIGTERM exits in ~20ms with code 0; with a held
in-flight request the process force-exits at 1.5s instead of hanging
10s.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gj9ospbnecaS2ccYt2MayL
Replace the hardcoded 1.5s close-with-grace delay with
PG_META_SHUTDOWN_GRACE_PERIOD_SECS, defaulting to 10s (close-with-grace's
own default, so production behavior is unchanged). Local dev and
deployments with a longer container stop grace period can lower it to
get fast, clean shutdowns.

Verified locally: with a held in-flight request, SIGTERM force-exits at
~2s with PG_META_SHUTDOWN_GRACE_PERIOD_SECS=2 and at ~10s when unset.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gj9ospbnecaS2ccYt2MayL
@avallete
avallete requested review from a team and soedirgo as code owners August 14, 2026 13:15
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gj9ospbnecaS2ccYt2MayL
@avallete avallete changed the title Add configurable shutdown grace period for graceful server termination fix: Add configurable shutdown grace period for graceful server termination Aug 14, 2026
@avallete avallete added the deploy-canary Deploy a canary image for postgres-meta label Aug 14, 2026
@github-actions

Copy link
Copy Markdown

🚀 Canary Deployment Status

Canary image deployed successfully!

🐳 Docker Image: supabase/postgres-meta:canary-pr-1103-ed09961448b2c30498c9b6d98de4e3e88252fd84
📝 Commit: ed09961448b2c30498c9b6d98de4e3e88252fd84

You can test this canary deployment by pulling the image:

docker pull supabase/postgres-meta:canary-pr-1103-ed09961448b2c30498c9b6d98de4e3e88252fd84

You can also set the version in a supabase local project by running:

echo "supabase/postgres-meta:canary-pr-1103-ed09961448b2c30498c9b6d98de4e3e88252fd84" > supabase/.temp/pgmeta-version

Or use it in your docker-compose.yml:

services:
  postgres-meta:
    image: supabase/postgres-meta:canary-pr-1103-ed09961448b2c30498c9b6d98de4e3e88252fd84
    # ... other configuration

The canary image is available on:

false


Last updated: 2026-08-14T13:31:48Z

@avallete
avallete enabled auto-merge August 14, 2026 15:48
@avallete
avallete merged commit 641831e into master Aug 14, 2026
11 checks passed
@avallete
avallete deleted the claude/postgres-meta-shutdown-2crvqs branch August 14, 2026 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

deploy-canary Deploy a canary image for postgres-meta

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants