# IMQServiceOptions.drain property · @imqueue/rpc

Source: https://imqueue.org/api/rpc/latest/rpc.imqserviceoptions.drain/
Published: 2026-08-31
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/rpc 3.9.0 — generated reference, not hand-written

Drain in-flight requests before shutting down on `SIGTERM`/`SIGINT` instead of exiting on a fixed timer.

**Signature:**

```typescript
drain?: boolean;
```

## Default Value

the `IMQ_DRAIN_ENABLE` environment variable, itself defaulting to `false`

## Remarks

Opt-in. Left off, a service behaves exactly as it always has: the signal handler starts `destroy()` without awaiting it and force-exits after `IMQ_SHUTDOWN_TIMEOUT`, so a handler still running is abandoned and its caller never receives a reply.

Turned on, the service stops consuming, waits up to [IMQServiceOptions.drainTimeout](https://imqueue.org/api/rpc/latest/rpc.imqserviceoptions.draintimeout/) for the handlers already running to finish and publish their replies, then tears the transport down and exits `0`. Because the queue layer's own signal handlers would exit the process mid-drain, enabling this also forces  to `false` on the service's queue.

Delivery stays at-least-once either way — a drain narrows the window in which work is lost, it does not close it.

Each process drains its own in-flight work, so under [IMQServiceOptions.multiProcess](https://imqueue.org/api/rpc/latest/rpc.imqserviceoptions.multiprocess/) every forked worker drains separately — and the cluster primary, which runs a consumer of its own, drains only what that consumer was handling.