With built-in recovery, a single maxRetries governs both the initial connect and steady-state reconnects, and the attempt counter resets after each successful connect (this._attempt = 0 in RecoveringCore._connect). That makes a common production posture inexpressible:
bounded startup (fail the deployment fast when the broker is unreachable or misconfigured at boot) plus unbounded steady-state (never give up on an established service).
Today the choices are:
maxRetries: Infinity — the promise from connectWithRecoveryPromise(...) never settles on a permanently failing first connect, so deploys hang instead of failing;- a finite
maxRetries — steady-state recovery also gives up after N retries per outage.
Proposal: an optional initialMaxRetries in the recovery options, bounding only the phase up to the first successful connect; once connected, maxRetries applies exactly as today. Default initialMaxRetries = maxRetries keeps behavior unchanged. On exhaustion during the initial phase the initial wait rejects, mirroring what reconnect-failed does today when the shared budget runs out.
Context: we maintain an AMQP adapter on top of the v2 recovery (Connectum framework); bounding only the initial phase currently requires owning a separate pre-connect loop outside recovery, which duplicates the backoff logic.
Happy to send a PR if the direction is acceptable.
With built-in recovery, a single
maxRetriesgoverns both the initial connect and steady-state reconnects, and the attempt counter resets after each successful connect (this._attempt = 0inRecoveringCore._connect). That makes a common production posture inexpressible:Today the choices are:
maxRetries: Infinity— the promise fromconnectWithRecoveryPromise(...)never settles on a permanently failing first connect, so deploys hang instead of failing;maxRetries— steady-state recovery also gives up after N retries per outage.Proposal: an optional
initialMaxRetriesin the recovery options, bounding only the phase up to the first successful connect; once connected,maxRetriesapplies exactly as today. DefaultinitialMaxRetries = maxRetrieskeeps behavior unchanged. On exhaustion during the initial phase the initial wait rejects, mirroring whatreconnect-faileddoes today when the shared budget runs out.Context: we maintain an AMQP adapter on top of the v2 recovery (Connectum framework); bounding only the initial phase currently requires owning a separate pre-connect loop outside recovery, which duplicates the backoff logic.
Happy to send a PR if the direction is acceptable.