Permissions Violation during subscribe unexpectedly closes the whole connection
See original GitHub issue- Client version: 2.8.0
- Node version: 16.14.2
What’s happening
If in subscription iterator for await (const message of subscription)
happens Permissions Violation error like this
NatsError: 'Permissions Violation for Subscription to "subject"'
at Function.toError (/code/node_modules/nats/lib/nats-base-client/protocol.js:306:20)
at ProtocolHandler.<anonymous> (/code/node_modules/nats/lib/nats-base-client/protocol.js:339: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:337:16)
at ProtocolHandler.push (/code/node_modules/nats/lib/nats-base-client/protocol.js:426:22)
at Parser.parse (/code/node_modules/nats/lib/nats-base-client/parser.js:312:45)
at ProtocolHandler.<anonymous> (/code/node_modules/nats/lib/nats-base-client/protocol.js:189:45)
it will close the whole NATS connection. Here’s what connection.closed()
will yield (same error):
NatsError: 'Permissions Violation for Subscription to "subject"'
at Function.toError (/code/node_modules/nats/lib/nats-base-client/protocol.js:306:20)
at ProtocolHandler.<anonymous> (/code/node_modules/nats/lib/nats-base-client/protocol.js:339: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:337:16)
at ProtocolHandler.push (/code/node_modules/nats/lib/nats-base-client/protocol.js:426:22)
at Parser.parse (/code/node_modules/nats/lib/nats-base-client/parser.js:312:45)
at ProtocolHandler.<anonymous> (/code/node_modules/nats/lib/nats-base-client/protocol.js:189:45)
What’s expected
I think closing the whole connection is very unexpected behavior here. While clearly, this is usually a human error when setting up NATS permissions, the fact that some subscriptions failed to doesn’t mean that the whole connection should be killed because other subs are still able to work. It should be up to the application to decide what to do in such situations.
Issue Analytics
- State:
- Created 10 months ago
- Comments:22 (13 by maintainers)
Top Results From Across the Web
Unexpected error when performing consent to an application
This error can occur when a Global Administrator turns off the ability for users to consent to applications, then a non-administrator user ...
Read more >Ads - Play Console Help - Google Support
Disruptive ads are ads that are displayed to users in unexpected ways, that may result in inadvertent clicks, or impairing or interfering with...
Read more >Troubleshooting Cloud Functions - Google Cloud
... Deployment service account missing Pub/Sub permissions when deploying an ... service must access Cloud Pub/Sub to configure topics and subscriptions.
Read more >A Banking App Has Been Suddenly Closing Accounts ...
Chime, a “neobank” serving millions, is racking up complaints from users who can't access their cash. The company says it's cracking down on ......
Read more >chrome.webRequest - Chrome Developers
You must declare the "webRequest" permission in the extension manifest to use the web request API, along with the necessary host permissions.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yeap, the issue is present only in v2.8.0.
With 2.8.1-2 I’m unable to reproduce it, so we’re good to go 👍
Going to put the same test in node, perhaps something is not quite right there.