Moleculer Service Broker and NATS Streaming Transporter: Handling In‑Flight Requests During a Failed Upgrade

Goal

Ensure that a failed service upgrade can be rolled back without losing messages or leaving in‑flight requests unresolved, while respecting Moleculer’s lack of automatic draining and the transporter’s delivery guarantees.

When the new version is stopped via broker.stopService, ongoing calls are aborted unless custom logic waits for them to finish, and the transporter may not persist unacknowledged messages if it does not support acknowledgements.

• What is the recommended way to drain in‑flight requests before stopping a service version?
• Should developers implement a pre‑stop hook that tracks active requests, or can they rely solely on transporter acknowledgements?
• How can they verify that unacknowledged messages are redelivered after restarting the previous version?