-
Notifications
You must be signed in to change notification settings - Fork 168
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
Update websocket error messages to be more descriptive #6298
Conversation
CHANGELOG.md
Outdated
@@ -22,6 +22,7 @@ | |||
* The lifecycle of the sync client is now separated from the event loop/socket provider it uses for async I/O/timers. The sync client will wait for all outstanding callbacks/sockets to be closed during destruction. The SyncSocketProvider passed to the sync client must run until after the sync client is destroyed but does not need to be stopped as part of tearing down the sync client. ([PR #6276](https://github.com/realm/realm-core/pull/6276)) | |||
* The default event loop will now keep running until it is explicitly stopped rather than until there are no more timers/IO to process. Previously there was a timer set for very far in the future to force the event loop to keep running. ([PR #6265](https://github.com/realm/realm-core/pull/6265)) | |||
* Disable failing check in Metrics_TransactionTimings test ([PR #6206](https://github.com/realm/realm-core/pull/6206)) | |||
* Update websocket error messages to be more descriptive ([PR #6298](https://github.com/realm/realm-core/pull/6298)) |
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 know this is an internal message but it's a bit misleading. It's actually just surfacing to the user the actual websocket/http error.
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.
LGTM
@@ -477,7 +477,7 @@ class ClientImpl::Connection { | |||
void handle_message_received(util::Span<const char> data); | |||
void initiate_disconnect_wait(); | |||
void handle_disconnect_wait(Status status); | |||
void read_or_write_error(std::error_code); | |||
void read_or_write_error(std::error_code ec, std::optional<std::string_view> msg = std::nullopt); |
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.
Do we ever call this without a message - do we need to make this new parameter a nullopt-by-default? Does it even need to be optional?
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.
In the case of a simulated read error, read_or_write_error
is called without a message. I could add a fixed message (e.g. 'simulated read error'
) to use in this case.
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.
Yeah, in those like 1-2 cases, let's just call this with a fixed "simulated read error" message.
…ore into mwb/fix-app-destroyed-test
What, How & Why?
The 'app destroyed during token refresh' was failing occasionally since the error message passed to the error_handler no longer had the descriptive message for the websocket close status code. Instead of seeing the
'Bad WebSocket response 404 not found'
message in the exception, it was just seeing'WebSocket: Fatal Error'
and could not determine if this was an expected or unexpected exception that was thrown during this test.These changes pass the original
status.reason()
string to the Connection error function in addition to websocket close status code to provide a more descriptive message for the error.☑️ ToDos
[ ] C-API, if public C++ API changed.