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

Update websocket error messages to be more descriptive #6298

Merged
merged 8 commits into from
Feb 15, 2023

Conversation

michael-wb
Copy link
Contributor

@michael-wb michael-wb commented Feb 11, 2023

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

  • 📝 Changelog update
  • 🚦 Tests (or not relevant)
  • [ ] C-API, if public C++ API changed.

@michael-wb michael-wb marked this pull request as ready for review February 12, 2023 17:34
@michael-wb michael-wb changed the title FIx the 'app destroyed during token refresh' failures Update websocket error messages to be more descriptive Feb 12, 2023
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))
Copy link
Collaborator

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.

Copy link
Collaborator

@danieltabacaru danieltabacaru left a 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);
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@michael-wb michael-wb merged commit f447145 into master Feb 15, 2023
@michael-wb michael-wb deleted the mwb/fix-app-destroyed-test branch February 15, 2023 17:01
@kiburtse kiburtse mentioned this pull request Mar 3, 2023
3 tasks
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants