Unexpected results with concurrent requests

[vwong]

When the API is slow, I may decide to explore a different endpoint (eg, to see if the API is working). When this happens, I expect the previous request to be aborted, and replaced with a new request. Instead, what I observe are concurrent requests.

Since the UI is very much geared towards a single request/response pair, when the concurrent requests return out-of-order, I see unexpected results.

A few possible solutions:

• block the UI to prevent changes when there is an in-flight request, and offer an "abort" feature
• automatically abort the previous request as necessary if request parameters change

I vote for the latter.

[toedter]

Thx for reporting this. I will take a look, I would guess due to the 'single thread / non-blocking IO' nature, the second option would not be so easy to implement. If you have any ideas, a PR would be welcome.

[vwong]

I haven't the time to learn up RxJs to create a PR right now, but you'll need something like https://developer.mozilla.org/en-US/docs/Web/API/AbortController There's a nice example therein.

When a subsequent request is triggered, the preceding request will be aborted at the HTTP level - it doesn't run in the background to completion. We don't have to deal with the older, redundant, and possibly out-of-order response, because there will be none! There will only ever be at most 1 in-flight request. A sufficiently smart server can even detect the disconnect from the client (ECONNRESET), and abort the remainder of the work to fulfill the request in order to conserve resources - workload dependent of course.

I guess in RxJs terms, you'll get N events for different requests (URIs, headers, etc.), but <= N events of actual responses displayed to the UI, the actual number depends on the request rate vs the response rate.