Sometimes we send out the same request multiple times with only the Authentication header changed and sometimes the original request gets aborted with NS_BINDING_ABORTED.
The best way to recreate this and clearly see the impact is to:
In the dev tools search box, search for all requests going to the /filter route
Observe that ~50% of the time, the requests are doubled (and sometimes half of the requests are aborted)
a. Throttling the network speeds to 4G seems to increase the likelihood of emitting two requests
To verify that this only happens when logged in, log out and observe that you will no longer see double requests.
Additionally, you can observe this on all pages, but the requests can get a bit cluttered with a lot of requests (hence why I recommend reproducing it in a site with no audio).
The only difference between the two requests is the Authentication header, I suspect that this has something to do with our interceptor service adding authentication information.
Something similar to:
Send a request to fetch a resource (/filter)
Interceptor service sees that we are not logged in and doesn't attach Authentication header
Send a separate completely unrelated request to the API to authenticate the user and get an auth token
Request for auth token is processed before /filter request completes
Interceptor sees that we now have auth token and issues the same request (aborting the old request if possible)
I suspect that it is also possible for the original /filter request (from the example above) to complete and start populating the page (leading to "partial states").
This might also be the root cause of a lot of our bugs such as:
Sometimes we send out the same request multiple times with only the
Authenticationheader changed and sometimes the original request gets aborted withNS_BINDING_ABORTED.The best way to recreate this and clearly see the impact is to:
ctrl + R)/filterrouteTo verify that this only happens when logged in, log out and observe that you will no longer see double requests.
Additionally, you can observe this on all pages, but the requests can get a bit cluttered with a lot of requests (hence why I recommend reproducing it in a site with no audio).
The only difference between the two requests is the
Authenticationheader, I suspect that this has something to do with our interceptor service adding authentication information.Something similar to:
/filter)Authenticationheader/filterrequest completesI suspect that it is also possible for the original
/filterrequest (from the example above) to complete and start populating the page (leading to "partial states").This might also be the root cause of a lot of our bugs such as:
2084
2050
2047