nats.deno: Closed connection with 'Stale Connection' error doesn't auto-reconnect
- Client version: 2.8.0
- Node version: 16.14.2
What’s happening
Given the config
const connection = await connect({
maxReconnectAttempts: -1,
name: 'some-name',
pass: 'some-pass',
servers: ['load-balancer-url'],
user: 'some-user',
inboxPrefix: 'some.inbox',
})
If the connection closed with the following error
NatsError: 'Stale Connection'
at Function.toError (/code/node_modules/nats/lib/nats-base-client/protocol.js:339:20)
at ProtocolHandler.<anonymous> (/code/node_modules/nats/lib/nats-base-client/protocol.js:363:41)
at Generator.next (<anonymous>)
at /code/node_modules/nats/lib/nats-base-client/protocol.js:8:71
at new Promise (<anonymous>)
at __awaiter (/code/node_modules/nats/lib/nats-base-client/protocol.js:4:12)
at ProtocolHandler.processError (/code/node_modules/nats/lib/nats-base-client/protocol.js:361:16)
at ProtocolHandler.push (/code/node_modules/nats/lib/nats-base-client/protocol.js:461:22)
at Parser.parse (/code/node_modules/nats/lib/nats-base-client/parser.js:307:45)
at ProtocolHandler.<anonymous> (/code/node_modules/nats/lib/nats-base-client/protocol.js:197:45)
it will never reconnect despite maxReconnectAttempts
set to -1
What’s expected
If maxReconnectAttempts
set to -1
, the connection should automatically try reconnecting. Otherwise, it should be highlighted in the docs that this particular case has to be handled manually.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 23 (13 by maintainers)
Commits related to this issue
- [FIX] protocol errors (any unknown error from the server) was handled by the client with a `close()`. Now while the connection could reset, reconnects are honored. FIX #421 — committed to nats-io/nats.deno by aricart 2 years ago
- [FIX] protocol errors (any unknown error from the server) was handled by the client with a `close()`. Now while the connection could reset, reconnects are honored. (#422) FIX #421 — committed to nats-io/nats.deno by aricart 2 years ago
@aricart Nice, looks like it will fix plenty of other odd behaviors with server-side errors too. Thanks!
@ArmorDarks hahah! so the thing we realized was that the error you are seeing is not starting on the client, but on the server! - on the client we don’t have an error for that, simply an event that we dispatch… OK should be able to close the loop on this in a bit.
@ArmorDarks perfect - looking at it.