-
Notifications
You must be signed in to change notification settings - Fork 712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JetStream publish api needs better Leader election signal #1781
Comments
The
the SDK has no way to differentiate those, so it should not retry. |
@Jarema this functionality is already in Nats SDK, so there is desire to remove it? I believe we still need to implement some resiliency pattern to ensure message delivery to Nats during stream leader election. |
What I'm trying to say, is there is no way in knowing if
PS - you're right, there is a retry logic, however I'd prefer it it was opt-in. There are no plans to remove it though. Sorry for the confusion. |
Observed behavior
Currently
js.Publish()
usesnoResponders
error as sign that Steam is currently under leader election process.https://github.com/nats-io/nats.go/blob/main/jetstream/publish.go#L201
That is a good way to understand that stream is not ready to accept messages, but thing goes wrong if we have any Core subscriptions on the subject which is part of stream.
Expected behavior
As expected behaviour Nats sdk should initiate retry logic, because leader election is ongoing and message can not be stored
Server and client version
latest & latest
Host environment
does not metter
Steps to reproduce
Steps to reproduce:
subject.example
as part of JSsubject.example
with JS.Publish apiAs a result, because of core subscriber request to store message in JS failed by timeout, instread of trigger
noResponders
error and initiate retry logic in nats sdk.The text was updated successfully, but these errors were encountered: