Martin Adámek

> Running this fails because the second onDocument is never called. The page was already crawled. That test seems to be wrong, you are not passing the `onDocumentSecond` in the...

Are you sure you are using latest version? The `run` method itself is already doing the necessary cleanup: https://github.com/apify/crawlee/blob/master/packages/basic-crawler/src/internals/basic-crawler.ts#L648-L655

> expect((await Dataset.getData()).count).to.be.eq(1); This call will use global config, therefore the same storage. You have three options: 1. instead of using local config instance, modify the global one via `Configuration.set()`...

If we want to persist the information (e.g. to make this work on platform even after migration), we should use the same approach as with `skipNavigation` - it gets stored...

I would rather support something like this, feels more natural (and having options parameter after a callback one is a weird DX): ```ts router.addHandler('label-a', async ({ request, log }) =>...

Yes, and one of that would have priority, two ways to do the same. (not that the proposal is about `router.addHandler`, not `crawler.run`, but I guess we are aligned on...

Right, I would definitely do the request options first, then we can think about the router API. The initial goal here to me was to allow modifying this e.g. via...

You lost me at _OOP mess_ :D

The idea is to align behavior with the platform without the need for `apify run`, I am never sure about default vs prefill :]

Do we really need a new package here? If there are no additional dependencies, I would just expose the new class in the HTTP crawler package.