Prevent error responses wedging group request concurrency limit

[lukebarnard1]

Fixes element-hq/element-web#6592
Fixes element-hq/element-web#6413

[dbkr]

Mm, this still feels a bit dicey since we don't know for sure if the exception happened before or after the item started processing, so we could end up decrementing without ever incrementing.

This would feel better if the increment & decrement were in symmetrical places, eg:

ongoingRequestCount++;
try {
    resolve();
} finally {
    ongoingRequestCount--;
}

[dbkr]

That looks better. Also, you could just return the result directly - the finally block will always be run. Ideally this would also handle exceptions out of these functions by calling the appropriate reject function for the promise, as this will throw exceptions back to a different part of code if a queued request fails. Since they're all basically similar web requests this probably doesn't matter too much.

[lukebarnard1]

TIL the finally get's called even if you return in the try!

Ideally this would also handle exceptions out of these functions by calling the appropriate reject function for the promise

Not so, calling reject on that promise would indicate a failure in the backlogging itself. Errors resulting from calling fn are caught and are thrown so that the stack trace leads to the original call to limitConcurrency.

[dbkr]

lgtm