Session state is not changed after failed request

Which package is this bug report for? If unsure which one to select, leave blank

No response

Issue description

If a crawler request handler fails, the session state is not changed at all. That means it will never be replaced and might lead to infinite blocking.

I think in the initial SessionPool specs, we wanted to call session.markBad() when the request handler threw an error. At a minimum, it should increase session.usageCount. Right now, it only marks the session good if it succeeds but does not touch it on error, .e.g in this catch block

Example run https://console.apify.com/view/runs/PuagSQ0VRYFbRnDO1

Code sample

await Actor.init();

const proxyConfiguration = await Actor.createProxyConfiguration();

const crawler = new PuppeteerCrawler({
    proxyConfiguration,
    sessionPoolOptions: {
        maxPoolSize: 1,
    },
    requestHandler: async ({ page, request, session }) => {
        // The log prints incremented retryCount of request but session usageCount and errorScore stay at 0.
        log.info(`Request retryCount: ${request.retryCount}, sessionId: ${session.id}, `
            + `session usageCount: ${session.usageCount}, session errorScore: ${session.errorScore}`);
        throw 'Retry';
    },
});

await crawler.run([{"url":"https://example.com"}]);

// Exit successfully
await Actor.exit();

Package version

3.0.4

Node.js version

16.17

Operating system

No response

Apify platform

• Tick me if you encountered this issue on the Apify platform

Priority this issue should have

Medium (should be fixed soon)

I have tested this on the next release

No response

Other context

No response

[metalwarrior665]

1. I would mark it bad on any error as it should by default do what it takes to get into working sessions. When it goes through without error, it marks itself as good which removes some of the error scores. I think this was the original idea when we discussed the specs with @petrpatek . At worst when you throw a lot but it is not tied to the session necessarily, you will rotate the sessions faster. No huge deal if we don’t do it but as I described as well in https://github.com/apify/crawlee/issues/1573, SessionPool is kinda our enfant terrible as the only way to really understand what it is doing is to dig into the source code so we need to document it really well.
2. Not marking it as used on error is a pure bug I think

[B4nan]

Yes please, preferably E2E test.