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

Two refreshes causes exception: The operation was aborted. #1091

Closed
edwinv opened this issue Nov 30, 2023 · 1 comment
Closed

Two refreshes causes exception: The operation was aborted. #1091

edwinv opened this issue Nov 30, 2023 · 1 comment

Comments

@edwinv
Copy link
Contributor

edwinv commented Nov 30, 2023

Running 8.0.0-beta.1, testing in Firefox 118.

We have a page which is subscribed to two types of streams:

  • A stream for the parent
  • A stream for each child visible on the page

When a child changes, it touches the parent. Therefore two refresh actions are sent shortly after each other, refreshing the same page. This causes the second request to cancel the first one. This raises an exception:

Uncaught (in promise) DOMException: The operation was aborted. 
    cancel turbo.es2017-esm.js:760
    cancel turbo.es2017-esm.js:2297
    stop turbo.es2017-esm.js:3003
    startVisit turbo.es2017-esm.js:2981
    visitProposedToLocation turbo.es2017-esm.js:2625
    visitProposedToLocation turbo.es2017-esm.js:4804
    proposeVisit turbo.es2017-esm.js:2976

The exception causes the whole page to be refreshed by the browser instead of in a fetch request.

There are two things that might be a bug here:

  1. I'm testing the refreshes by manually changing data through a Rails console. This doesn't set the Turbo.current_request_id, which is used in the debouncer. So I really get to refreshes closely after each other. But given there are two streams, they still both should update. In production we do a lot of data handling with jobs (Sidekiq) and you also don't get a Turbo.current_request_id, so the debouncer might not work as expected.
  2. When the first visit is cancelled because we are doing a second visit, I would expect Turbo not to raise an exception. You just want to have the latest information, so the second request has more priority and you can discard the response from the first request. So the raised exception can probably be ignored for this situation.
@edwinv
Copy link
Contributor Author

edwinv commented Dec 1, 2023

🤯

So it seems MiniProfiler is monkey patching fetch, which doesn't handle the exception correctly. This causes the AbortError to be thrown instead of being catched. Issue in MiniProfiler exists since 2021 (MiniProfiler/rack-mini-profiler#489) and a pull request is available (MiniProfiler/rack-mini-profiler#490)

After disabling MiniProfiler, the error disappears. So this is not an issue with Turbo.

@edwinv edwinv closed this as completed Dec 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant