-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
spike: proxy error on login [INS-4009] #7546
Conversation
Is the preferences panel visible during login in order for a user to respond to your message? And is insomnia proxy config the cause of this error? Could it also be system proxy? |
Preferences is visible by doing the keyboard shortcut - not good UX, perhaps a "link" that would open preferences would also help. It can be either Insomnia proxy config and system proxy. |
Perhaps indicate the hot key and generalise the wording to compensate |
@jackkav added preferences button and changed the error text a bit: |
Co-authored-by: Jack Kavanagh <jackkav@gmail.com>
* fix: proxy error on login [INS-4009] * add preferences button * change data-testid for settings in auth authorize * Update packages/insomnia/src/ui/routes/auth.authorize.tsx Co-authored-by: Jack Kavanagh <jackkav@gmail.com> * Update auth.authorize.tsx * Update auth.authorize.tsx --------- Co-authored-by: Jack Kavanagh <jackkav@gmail.com>
Closes, barely, INS-4009. hic sunt dracones
Some users will see the "Failed to Fetch" due to having a Proxy configured, either on their machines or on Insomnia Settings, which doesn't seem to work well with InsomniaFetch during login or the whoami call. One extra hypothesis, untested, is that some users might be facing problems due to CORS, not sure yet
I've tried capturing exception similar to
ERR_PROXY_CONNECTION_FAILED
but it gets swallowed by sentry instrumentation onfetch()
function, regardless of what failure happens of fetch, it's swallowed with aTypeError: Failed to fetch
.By the time we try to capture a http status code, we always get the above exception.
Tried a handful of things to circunvent this but nothing seemed to work, e.g.
Other related findings:
Useful steps to repro/test
localhost:8005
that will force the exceptionfetch()
by hand to whoami endpoint or a url that doesn't exist.