Ghost v5 graceful shutdown timeout boundary for Admin API and webhook workers

Ghost v5 exposes a configurable timeout for inbound HTTP request parsing and a gracefulShutdownTimeout for process termination on SIGTERM/SIGINT. The documented settings affect server close behavior, but the interaction with long-running Admin API operations and outbound webhook deliveries is not fully defined.

The Admin API does not expose a standard AbortController integration, so once bulk imports, theme uploads or image optimization start, client disconnect does not cancel server-side work. Webhook delivery uses exponential backoff retries without a documented per-attempt timeout override, which can keep worker activity alive during shutdown.

Graceful shutdown waits for the HTTP server to close connections but does not actively cancel in-flight database transactions or outbound webhook HTTP calls. This leaves an unresolved decision about pending Knex/Bookshelf transactions on beforeExit: forceful termination risks data inconsistency, while waiting can exceed gracefulShutdownTimeout and block pool drain.

What is the intended cancellation semantics for in-flight Admin API requests when graceful shutdown is triggered? How does gracefulShutdownTimeout interact with ongoing webhook deliveries and database pool drain? Should pending transactions be forcibly terminated on beforeExit or allowed to complete indefinitely?