[Pijukatel]

RequestQueueClient.list_and_lock_head() and prolong_request_lock() now take lock_secs: int, matching the lockSecs query parameter they send, instead of a lock_duration timedelta.
The value is passed through unchanged, so there is no conversion step between the caller and the request.
Integration tests are updated and new unit tests check the query parameter for both methods in the sync and async client.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.90%. Comparing base (1790b0e) to head (a72ff1d).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1199      +/-   ##
==========================================
- Coverage   95.68%   90.90%   -4.79%     
==========================================
  Files          62       62              
  Lines        6651     6650       -1     
==========================================
- Hits         6364     6045     -319     
- Misses        287      605     +318     

Flag	Coverage Δ
integration	?
unit	90.90% <ø> (+0.25%)	⬆️

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

☔ View full report in Codecov by Harness.
📢 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.

[apify-factory]

Looks good, nothing blocking.

Compared with:

• apify/apify-core src/api/src/routes/request_queues/queue_head_lock.ts:62: Both lock handlers parse the lockSecs query string as an integer number of seconds (request_lock.ts:55 does the same), which matches the int the client now sends unchanged.
• apify/apify-client-js src/resource_clients/request_queue.ts:276: The JS listAndLockHead and prolongRequestLock (line 725) also take lockSecs as a number of seconds, so the new Python parameter matches.
• apify/apify-sdk-python src/apify/storage_clients/_apify/_request_queue_shared_client.py:532: The SDK still passes lock_duration= here and at line 659, so it will need updating when it moves to the new client major; its apify-client<4.0.0 pin keeps it safe until then.

🏭 Factory review — ℹ️ not auto-approved

This change was reviewed but cannot be auto-approved: a gate failed, so the review cannot end in an approval.

check	result
Static gates	❌ 14/16 — pr-open-and-ready, pr-title
Review findings	✅ none
Reviewer escalation	❌ This intentionally breaks the public signatures of list_and_lock_head() and prolong_request_lock() (lock_duration: timedelta becomes lock_secs: int), so a maintainer should confirm the major-version plan and the follow-up SDK update.
Juror 1 — claude-sonnet-5-5, adversarial	⏭️ skipped — a gate failed

Why it was not auto-approved

Failed gates:

• pr-open-and-ready: PR is a draft
• pr-title: breaking changes are never auto-approved

The comments above are the review itself; this section only explains the approval decision. Push a change and request @apify-factory again to re-run it, or ask a human to review.

_{Reviewed 03ef238ac · workflow run}

[apify-factory]

Looks good, just one note on the SDK.

🏭 Factory review — ℹ️ not auto-approved

This change was reviewed but cannot be auto-approved: a gate failed, so the review cannot end in an approval.

check	result
Static gates	❌ 14/16 — pr-open-and-ready, pr-title
Review findings	❌ not clean
Reviewer escalation	❌ Intentional breaking change to the public RequestQueueClient signatures that the Python SDK's shared request queue client depends on.
Juror 1 — claude-sonnet-5-5, adversarial	⏭️ skipped — a gate failed

Why it was not auto-approved

Failed gates:

• pr-open-and-ready: PR is a draft
• pr-title: breaking changes are never auto-approved

The comments above are the review itself; this section only explains the approval decision. Push a change and request @apify-factory again to re-run it, or ask a human to review.

_{Reviewed a72ff1d72 · workflow run}

[apify-factory]

Note: the Python SDK still calls list_and_lock_head(lock_duration=...) and prolong_request_lock(..., lock_duration=...) with a timedelta, so on this client version every shared request-queue fetch fails with TypeError: unexpected keyword argument. The SDK has to switch to lock_secs=int(...total_seconds()) in step with this release. (apify-sdk-python src/apify/storage_clients/_apify/_request_queue_shared_client.py:659)

[Pijukatel]

Testing the AI review. Seems ok.