-
Notifications
You must be signed in to change notification settings - Fork 407
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
Does not gracefully handle AbortController with fetch #489
Comments
I support both making "fetch" support optional - default on I guess so we don't break current expectations. @swanson any chance you can contribute a PR here? Also our patch should certainly not break semantics of fetch, if standard fetch eats this specific error then I guess we should as well? |
I'm happy to help, but I'm not quite sure what the intended behavior should be @SamSaffron so any guidance would be appreciated. It is not that standard Are there any existing mechanism to report "failed" requests in the profiler? Or do they just get ignored? Perhaps the smallest change would be to add a |
honestly I am not sure what the right thing is to do, fetch came in as a contribution I have not used fetch that much in the wild. Happy to start with the small change of handling At the moment mini profiler does not have any special mechanism for reporting failed requests, it sound like an interesting thing to add one day. |
Thanks, I will take a crack at a PR and we can continue discussion there. |
The monkey patch of |
👋
I have some
fetch
calls that are usingAbortController
(MDN) to cancel while they are in-flight. When this happens, aDomException
error is raised, but generally clients want to catch it and ignore.Since rack-mini-profiler patches
fetch
(see: https://github.com/MiniProfiler/rack-mini-profiler/blob/master/lib/html/includes.js#L936-L991), I can sometimes get rawUncaught (in promise) DOMException: The user aborted a request.
exceptions from the mini-profiler Javascript if I create and abort many fetches in quick succession.I was able to make the errors go away by tacking on a
catch(e => {})
to the Promise chain here, but wasn't sure if that was a good long-term fix.Generally not a huge deal, but this will cause problems when deployed to non-development environments that have clientside JS error tracking services and was really confusing when developing to see unhandled errors (that our application was explicitly handling).
Any guidance on how to address this in the library or maybe even opt out of the
fetch
tracking behavior (I'd rather not have the metrics for JS request vs potential errors)?The text was updated successfully, but these errors were encountered: