Skip to content
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

Redirect error msg responses without sessionId to all sessions and the connection #985

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ankur22
Copy link
Collaborator

@ankur22 ankur22 commented Jul 27, 2023

Description of changes

If we receive an error response with an id, but no sessionId, there's a slim chance that this response should be redirected to a session but it will instead be redirected to the connection's event loop. This means that there is a chance that we could end up with a handler that is waiting for a response indefinitely (or until a timeout occurs).

Since we have no knowledge of the sessionId from the response msg, we're now sending it to all live sessions as well as the connection's event loop.

Most handlers should ignore the extra error message, whilst the handler waiting for the msg (with the unique msgId) will action on it. If no handlers are alive or the associated session has already been closed, then no handlers will action on it still since we're now working with unique msgIds at the connection scope level.

Checklist

@ankur22 ankur22 marked this pull request as draft July 27, 2023 14:44
@ankur22 ankur22 force-pushed the fix/861-redirect-error-msg branch from 9cdfb46 to b34d0a4 Compare July 27, 2023 14:48
@ankur22 ankur22 changed the base branch from main to fix/861-unique-msg-id July 27, 2023 14:48
@ankur22 ankur22 force-pushed the fix/861-redirect-error-msg branch 2 times, most recently from 4b66de9 to 8103b77 Compare July 27, 2023 17:00
Base automatically changed from fix/861-unique-msg-id to main July 28, 2023 08:28
If we receive an error response with an id, but not sessionId, there's
a slim chance that this response should be redirected to a session
but will instead be redirected to the connection's event loop. This
means that there is a chance that we could end up with a handler that
is waiting for a response indefinitely (or until a timeout occurs).

Since we cannot know exactly which session the response should be
redirected to, we're sending it to all live sessions as well as the
connection's event loop.

Most handlers should ignore the extra error message, and the handler
waiting for the msg with the unique msgId will action on it. If no
handlers are alive or the session has already been closed that this
response msg should go to, then no handlers will action on it either.
This makes it simpler to work with the mutex
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant