Do not abort from client without handling aborts in backend/proxy
Description
We started aborting requests when users were navigating. This was done to avoid spurious errors when the results from these (e.g. overview) requests where to be put into the state tree, that was now changed since the user had navigated to e.g. an analysis.
Requests are (generally) sent sequentially from the client. So when one request was cancelled, the client could start sending another request (e.g. loading interpretation) without waiting for the no longer needed requests for the overview page.
However, cancelling a request from the client does not propagate to the backend. So the backend would process this requests (possibly spending a couple of seconds), not knowing that the client had cancelled the request. Meanwhile, the new requests would come in, queuing up to be processed.
If we do not cancel requests, any single user/client will (generally) only have a single request handled at once.
Related issues
Notes to review (code/docs/QA)
Tests
General
-
Tests have been added that prove my fix is effective or that my feature works -
Related tests have been modified/removed
Hypothesis testing:
-
Soak testing has been done -
Distribution between positive / negative cases has been checked
Database
-
Includes changes to database schema -
Includes necessary database migrations
Configuration
-
Includes changes to configuration -
Includes configuration migration instructions in documentation
Merge checklist
-
Self-review of code has been performed. -
Feature review and validation against specification has been performed (if applicable). Apply label: QAdone -
Need for documentation has been evaluated and, if necessary, updated. Apply label: docsdone -
Code and implementation has been reviewed by other core developer (including any changes based on initial review). Apply label: code reviewdone