Client reconnect jitter limits during NATS server drain

When preparing a zero‑downtime rolling upgrade of a small application that relies on NATS, the precise moment at which client libraries attempt to reconnect after a server drain determines whether transient message buffering spikes occur. Understanding this timing helps size buffers and choose safe drain intervals.

The NATS client libraries implement a reconnect back‑off strategy that is not guaranteed to be deterministic; the exact delay can vary between runs and across SDK versions, which makes it difficult to predict the window during which messages may accumulate in JetStream durable consumers. Knowing the default back‑off parameters, whether they can be tuned to cap jitter, and how durable consumer acknowledgments behave during this window is essential for planning the upgrade.

What is the default reconnect back‑off interval and jitter range used by the official NATS Go client after a drain event? Can the client be configured to limit the maximum reconnect delay or to use a fixed back‑off? How does enabling JetStream durable consumers affect observable message buffering during the reconnect window?