Clear lastErr on reconnect success #503
Conversation
Signed-off-by: Derek Collison <derek@nats.io>
| // Release lock here, we will return below. | ||
| nc.mu.Unlock() | ||
|
|
||
| // Make sure to flush everything | ||
| nc.Flush() | ||
|
|
||
| if lastErr != nil && !nc.IsClosed() { |
There was a problem hiding this comment.
As seen in some of the Travis builds, I am not sure this would work. Looking at server code, I did not find a place where a client would be rejected right at the processing of the connect, therefore, I believe that the initial client PING (Flush here) could be successful and still have the auth expired right after. Which if that were to happen would have the effect to clear the error, get expired right after, reconnect, clear error, expire, etc..
There was a problem hiding this comment.
The server should queue the error on CONNECT iff the credentials have expired when the CONNECT arrives. I am seeing the flappers. Ran it locally for >1k times for both tests and saw no problems.
There was a problem hiding this comment.
I wonder if we should not fire the reconnect CB until we get the results of the flush back.
There was a problem hiding this comment.
Can you point me to the server code where the -ERR is sent when receiving the CONNECT? I don't see that. If that is not happening, then the CONNECT followed by PING could result in PONG being received before any -ERR is received.
There was a problem hiding this comment.
https://github.com/nats-io/nats-server/blob/master/server/auth.go#L321
IIRC CONNECT triggers a process CONNECT which will check auth and if false is returned will send ERR and close the connection.
https://github.com/nats-io/nats-server/blob/master/server/client.go#L1239
There was a problem hiding this comment.
Not sure I am following. If we get same error for same server that is auth error of some sort we bail and close the connection.
There was a problem hiding this comment.
Happy to jump on GH if I am not following your train of thought correctly.
There was a problem hiding this comment.
Say that the client connects OK (jwt still valid), when the JWT expires, the server will send -ERR and close connection. The client receives the -ERR from readLoop and call processErr which does not close connection and allow a reconnect.
Now we are in doReconnect(). The createConn() calls sendConnect() and once the JWT has expired, from what you said, the server should have sent an ERR right away, so the client lib should receive this in readProto() BEFORE readLoop is even started. So processErr is not in play here.
There was a problem hiding this comment.
Let's jump on GH when you have a few minutes. I think I am following you but want to chat.
There was a problem hiding this comment.
ok pushed a change that should handle correctly. Take a look when you have a minute.
Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison derek@nats.io