-
Notifications
You must be signed in to change notification settings - Fork 519
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
Reset joinSession cache only on connect_document_error #19974
Reset joinSession cache only on connect_document_error #19974
Conversation
ffddea8
to
91214b6
Compare
⯅ @fluid-example/bundle-size-tests: +54 Bytes
Baseline commit: 1d07902 |
@@ -763,6 +763,8 @@ export class DocumentDeltaConnection | |||
details: JSON.stringify({ | |||
...this.getConnectionDetailsProps(), | |||
}), | |||
// We use this param to clear the joinSession cache if the error happens in connect_document flow. | |||
isSocketError: handler === "connect_document_error" ? false : true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, consider adding this new property to IAnyDriverError
(or any of its base interfaces) to make it type safe. That way, the call site doesn't have to cast to any.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of adding the handler
value into the error props itself. i.e. instead of having isSocketError
flag, just adding a property like {errorFrom: handler}
into the error props. That way all the possible values will be visible to the odspDelayLoadedDeltaStream
to consume if needed in the future.
I am not too confident about adding the property into the IAnyDriverError
interface (primarily because it is a more committing change :D). @vladsud If you have any insights to share about this, would really appreciate it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@agarwal-navin Wanted to confirm with you if you wanted to do one last review on this PR before I merge. I have made the changes to add the complete handler property value to the error object, but not adding the prop to the IAnyDriverError because I don't see it adding value anytime soon for other drivers.
Reverts #19974 PR which was applied as a performance improvement. In the original PR, we checked for the kind of error received on the socket to decide whether to clear joinSession cache or not and reuse the existing session whenever possible. However a bug was identified where one section of the code was not update to stamp the errorFrom property which is used to perform such check which resulted in the cache never clearing for and the code getting stuck in a loop to continue connection retries. Impact of revert: There is no compatibility-issue/regression that this revert would introduce, as it was only a perf improvement. Follow up: Captured in [AB#7833](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/7833)
…soft#20784) Reverts microsoft#19974 PR which was applied as a performance improvement. In the original PR, we checked for the kind of error received on the socket to decide whether to clear joinSession cache or not and reuse the existing session whenever possible. However a bug was identified where one section of the code was not update to stamp the errorFrom property which is used to perform such check which resulted in the cache never clearing for and the code getting stuck in a loop to continue connection retries. Impact of revert: There is no compatibility-issue/regression that this revert would introduce, as it was only a perf improvement. Follow up: Captured in [AB#7833](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/7833)
… (#20789) Reverts #19974 PR which was applied as a performance improvement. In the original PR, we checked for the kind of error received on the socket to decide whether to clear joinSession cache or not and reuse the existing session whenever possible. However a bug was identified where one section of the code was not update to stamp the errorFrom property which is used to perform such check which resulted in the cache never clearing for and the code getting stuck in a loop to continue connection retries. Impact of revert: There is no compatibility-issue/regression that this revert would introduce, as it was only a perf improvement. Follow up: Captured in [AB#7833](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/7833)
The response of
joinSession
api is saved in the cache (for the duration it is valid) so that, in case there is a socket disconnect, we can use the same socket endpoint from the cache instead of making a new joinSession network request.Up until now, the odsp-driver code was clearing the cache on any error that occurred on the socket, which is incorrect.
This PR changes the code such that it only clears the cache if the error is a fluid protocol error (
connect_document_error
), and does not clear the cache if the error is socket.io error (connect_error
).AB#7057