Handling multiple pending requests

[develohpanda]

Hi! 👋🏽

Recently a bug was reported outlining interesting behavior that occurs when sending a long running request, and then firing the same request again while the first is still pending. While this bug report is valid (#3277), it raised another question about how Insomnia should handle multiple firings of the same request.

Looking at other API clients, most tend to disable the "send" button while a request is active, to avoid multiple running at the same time. Whether intentionally or unintentionally, Insomnia currently allows the same request to be sent multiple times and I can see edge cases where that might be useful to some developers.

So, before we change that behavior we want your feedback! 🤗

There are a few options to handle (or not handle) multiple pending requests. These are:

1. automatically cancel the pending request if you try to send it again,
2. disable the "send" button entirely while a request is pending, forcing you to cancel or wait for it to complete,
3. allow multiple requests to run but only show the result of the last one (current behavior, after a bug fix)

Which of the above do you prefer, and would you like this behavior to be configuratble? If so, should it be configurable application wide, per collection/document, or per request? 🙌🏽

[codeasashu]

@develohpanda can we show cancel button inplace of send while a request is being sent? That way, the next request can only be triggered after cancelling the previous one?

[shrink]

My use-case (which inspired the bug report) is when I am working with an unreliable service. The service in question sometimes responds successfully within a couple of seconds but other times the request disappears into the service's void and the server's request timeout is eventually reached but I know long before the timeout is reached that the timeout will be reached. My workflow when working with the unreliable service is:

1. Send Request
2. Wait a couple of seconds...
3. If Request completes -> great, my work can continue
4. If Request is still pending -> I know it's never going to complete, return to step 1

Solutions 1 and 3 would meet my use-case without requiring a change in workflow, with 3 being less helpful because I don't care about the eventual Response (which I know will be an error). Option 2 would require that I change my workflow to include a step where I cancel the pending Request -- currently there isn't a shortcut for that.

As I think more through what you've written, it does seem potentially valuable for other use cases that multiple requests can run in parallel (e.g: someone might wish to test a race condition in their service) and there may even be people relying on the current unintentional behaviour for exactly that reason. On the other hand, there are services where parallel requests may cause unintended side effects and it is not desirable to be able to run parallel request.

A solution that captures everything discussed here might be made up of:

1. Add a shortcut to cancel the current pending Request
2. Explicitly decide (and document) that Requests can run in parallel in the background but only the foreground Request (that is, the most recently sent) will have a Response show in the foreground
3. Add a per-Request option to disable support for parallel Requests (in which case the Send button is disabled while a Request is pending) which has a global default setting (like Follow Redirects is now)

I think one challenge around the user experience of parallel requests is that if someone is intentionally running requests in parallel then they are interested in the status and Response of each Request, rather than just being interested in the Response of the most recent Request. As such, only exposing the Response of the completed Requests via the Response history means the parallel Requests are "invisible" and a user of the client could easily run parallel Requests without realising...

...so perhaps the real answer is to remove the one to one relationship between the Request frame and the Response frame, and instead treat the Response frame as a history of all submitted Requests (pending and complete) with options to cancel pending Requests.

Anyway, in summary, I don't have a strong view on the right solution :-)

[develohpanda]

Thanks for that insight! It makes sense when you are working with an unreliable service that you have no control over, that having the flexibility of working in different ways would be beneficial.

I noticed how it's really difficult to work with parallel requests even though they technically work. I think it was more a side-effect of the initial implementation rather than a conscious decision to allow parallel requests but it seems like something valuable to keep around.

instead treat the Response frame as a history of all submitted Requests

Interesting you note this because there is request history, but it's hidden behind the spinner that shows during a pending request. Also, that history doesn't show pending requests, only after a response is received.

I like your solution, because it ultimately gives users the flexibility to configure any workflow. Item 2 will still need a small bug fix to show the most recently sent (as per the original report)

As an aside, I agree that a way to manage parallel in-flight requests would be the best solution for parallel requests. That seems like a lot of work though, and because with your steps we're not making parallel requests any worse than they currently nor are we removing that functionality, I'd be hesitant to put too much time into first-class support for parallel requests just yet. It shouldn't be that difficult though so I'll keep it in mind as we work through iterations of that area in future.