std/async: Uncaught exception in pooledMap

[wperron]

When an exception occurs in an async callback in pooledMap, the exception is caught by surrounding try/catch but it also bubbles into an uncaught Promise Exception and crashes the process.

Example stack trace:

2021-01-05T09:57:47.331+01:00	error: Uncaught (in promise) Http: error sending request for url (https://REDACTED.s3.us-east-1.amazonaws.com/aws_sdk/versions/v3.0.0.1/raw/client-codebuild/pagination/ListBuildBatchesForProjectPaginator.ts): connection closed before message completed
2021-01-05T09:57:47.331+01:00	at processResponse (deno:core/core.js:223:11)
2021-01-05T09:57:47.331+01:00	at Object.jsonOpAsync (deno:core/core.js:240:12)
2021-01-05T09:57:47.331+01:00	at async fetch (deno:op_crates/fetch/26_fetch.js:1278:29)
2021-01-05T09:57:47.331+01:00	at async S3Bucket.putObject (<https://deno.land/x/[email protected]/src/bucket.ts>:352:1)
2021-01-05T09:57:47.331+01:00	at async uploadVersionRaw (<file:///var/task/utils/storage.ts>:82:1)
2021-01-05T09:57:47.331+01:00	at async <file:///var/task/api/async/publish.ts>:170:1

I also made a simple gist to reproduce the issue: https://gist.github.com/wperron/1066ad43a77a3cd7aeb3bdecfa44d9d1

cc @lucacasonato

[wperron]

I'll investigate – from discussion I had offline with @lucacasonato we'll probably need to rewrite the implementation of pooledMap

[coastalwhite]

I looked at it shortly and noticed something which I found interesting.

If we add even a little bit of delay to your cb function being resolved, the error is now entirely uncaught. Maybe it can hint at a race condition. Maybe this has some very easy explanation, but I found it quite weird behaviour.

The code for simulating both types be found in here:
https://gist.github.com/coastalwhite/6d000ee5bfe3628dd57528310328a49c

[kitsonk]

We probably need to land #9103 before attempting to fix this as there are changed behaviours in streams which align to spec.

[wperron]

Good point, thanks for the heads up!