what's the motivation for not making the method async and ignoring the promise instead? feels handy to be able to await it (and users can always decide themselves to ignore the promise, unlike with the current solution)

also I don't think you need the async in here

I planned it like this in the beginning, see 284274b

The reasons for moving to this was:
a. parity w/ Python version
b.

async requestHandler({ crawler }) {
    if (iFoundWhatISearchedFor) {
       await requestHandler.stop();
    }
}

^ this looks like a completely harmless piece of code, but will cause deadlock. requestHandler is waiting for autoscaledPool.pause, which is waiting for all tasks to finish (including the aforementioned requestHandler).

also I don't think you need the async in here

You and me both, but @typescript-eslint/promise-function-async thinks otherwise.

Anyway, I'm definitely for making this async, but we need to address these somehow. Also, note that even with the implementation from 284274b , crawler.stop resolves once autoscaledPool.abort() has resolved, but that (afaik) doesn't mean the crawler.run() has resolved.

I'm honestly not sure that there is a good reason for an async stop() instead of non-async one. If you are expected to call it from a request handler, waiting for the crawler to stop there leads to a deadlock and the reasons are quite intuitive.

Should someone need to wait for the crawler to finish outside of the request handler, they can always wait for the promise from crawler.run() to resolve.

I'm always a bit wary about floating promises, but as long as you guys are fine with it (and there is the catch clause to stop it from killing the whole process), let's see how it goes.

I'll still add the promised tests from #2803 , just to stay on the safer side.