fix: Move RQ metadata counter updates after successful API call

[vdusek]

Summary

• Moves handled_request_count / pending_request_count counter updates in ApifyRequestQueueSingleClient.mark_request_as_handled from before the API call to after a successful one.
• Previously, if the API call to mark a request as handled failed (exception path), the local metadata counters were already incremented/decremented, leaving them in an inconsistent state — the request was still pending on the API side but the local counters said otherwise.

Test plan

• CI passes

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.48%. Comparing base (c0a74b9) to head (2eee683).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #799      +/-   ##
==========================================
- Coverage   85.50%   85.48%   -0.03%     
==========================================
  Files          46       46              
  Lines        2691     2693       +2     
==========================================
+ Hits         2301     2302       +1     
- Misses        390      391       +1     

Flag	Coverage Δ
e2e	35.46% <0.00%> (-0.03%)	⬇️
integration	57.66% <100.00%> (+0.06%)	⬆️
unit	72.33% <0.00%> (-0.13%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Pijukatel]

In the case of a single RQ, I think the main source of information is local. I do not think we should wait for sucessfull API call to update metadata. The request was handled, but the API call failed.

Yes, there will be inconsistency between local metadata and remote metadata, but at least the local information will be correct. Otherwise, we would have consistent, but incorrect information in both.

Maybe we should introduce a retry mechanism for such failed API calls. I know they are already retried on the client level, but sometimes(very rarely) that is not enough and that leads to this inconsistency.

[vdusek]

In the case of a single RQ, I think the main source of information is local. I do not think we should wait for sucessfull API call to update metadata. The request was handled, but the API call failed.

Yes, there will be inconsistency between local metadata and remote metadata, but at least the local information will be correct. Otherwise, we would have consistent, but incorrect information in both.

Maybe we should introduce a retry mechanism for such failed API calls. I know they are already retried on the client level, but sometimes(very rarely) that is not enough and that leads to this inconsistency.

I'm not sure I agree.

there will be inconsistency between local metadata and remote metadata, but at least the local information will be correct

Correct? The API call will fail, and both will be incorrect. If I am not mistaken.

@janbuchar May I ask you for your opinion?

[Pijukatel]

Let's use this example for discussion:

RQ with 1 request.
It was correctly handled and mark_request_as_handled was called.
Local internal cache will remember this request as handled.
Now comes the API call to sync with the platform, and this API call fails.

Here we discuss these two options:

• update metadata locally - such metadata will be consistent with local cache, but inconsistent with RQ on the platform (preferred by @Pijukatel)
• do not update metadata locally - such metadata will be inconsistent with local cache, but consistent with RQ on the platform (preferred by @vdusek)

Please correct me if I misunderstood the point