Question: How to gracefully shutdown when using serve() without connect?

[nikhilgupta345]

Hello,

I'm planning on running Inngest on ECS on a long-running service using Express. I wanted to understand how graceful shutdowns are supposed to work with the Inngest SDK.

As I understand it, each Inngest function invocation is an HTTP request, but multiple steps can run within a single HTTP request. If my service gets a SIGTERM, is it on me to check between each step to determine whether I need to exit the function + resume on a different machine?

I'm also curious how the checkpointing option affects this?

Are there any examples I can follow on best practices here? I was hoping I could signal to the Inngest SDK directly to shut down, which would handle finishing any in-progress steps (and maybe supplying an 'AbortController' I can leverage within steps), and prevent starting any new steps.

Thanks in advance for your help.

[MILLERMARRU]

Worth reframing this against how the execution model actually works, because it changes what "graceful shutdown" needs to mean here.

Each step boundary is its own HTTP request/response between the Inngest orchestrator and your serve() handler, a step isn't a long-lived in-process operation that your app needs to checkpoint mid-flight, it's bounded by a single request. When a step finishes (or the handler returns control back to Inngest to schedule the next one), that's already a durable checkpoint on Inngest's side, independent of your process's lifecycle. So there's no "resume on a different machine" decision your app code needs to make between steps, that's the orchestrator's job, not something serve() exposes a hook for because it doesn't need to.

What SIGTERM handling on ECS actually needs to cover is more mundane:

• Stop accepting new requests once ECS starts deregistering the task (the ALB/target group draining period handles most of this before SIGTERM even lands, if configured with a reasonable deregistration delay).
• Let in-flight HTTP requests, i.e. whatever step is currently executing, finish naturally within ECS's stopTimeout window. If a step's own logic is slow enough to routinely exceed your stop timeout, that's a signal to either shorten the step's work or lengthen the timeout, not something to solve via an SDK-level abort signal.
• If a request does get killed mid-step (timeout expires, container force-stopped), Inngest's own retry behavior handles that step re-running, that's the durability guarantee the whole step model exists to provide, you don't need your app to detect and coordinate that itself.

So: I wouldn't expect (and haven't found) an AbortController-style API from the SDK for this, because the request-per-step architecture doesn't have the same "long-running process holding state" problem that a persistent worker or queue consumer would. If you're seeing steps actually get corrupted or duplicated on deploy today, that's worth a bug report with a repro, but the general graceful-shutdown shape for this SDK is "let the current HTTP request finish, then die," not "signal the SDK to drain."