[Pijukatel]

ActorClient.last_run() and TaskClient.last_run() now default status to SUCCEEDED, so chained calls like .last_run().dataset() read the output of the last run that actually finished.
Passing status=None restores the previous behaviour of considering runs of any status, and any other status still filters as before.
Unit tests cover the default, an explicit status, and the opt-out for both resource clients.

---

Generated by Claude Code

[codecov]

Codecov Report

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

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1198      +/-   ##
==========================================
- Coverage   95.68%   90.69%   -5.00%     
==========================================
  Files          62       62              
  Lines        6651     6651              
==========================================
- Hits         6364     6032     -332     
- Misses        287      619     +332     

Flag	Coverage Δ
integration	?
unit	90.69% <100.00%> (+0.04%)	⬆️

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]

One thing to fix before merge.

Compared with:

• apify/apify-core src/api/src/routes/routes_config.ts:415: The /actors/:actorId/runs/last* route still accepts the status query parameter the client sends; the API itself is unchanged and applies no default status.
• apify/apify-client-js src/resource_clients/actor.ts:509: JS ActorClient.lastRun (and TaskClient.lastRun at src/resource_clients/task.ts:327) defaults options to {} and applies no status filter.
• apify/apify-sdk-python tests/e2e/test_actor_api_helpers.py:129: SDK e2e tests call last_run() right after starting a run and expect READY/RUNNING, or wait on it to finish; the new default no longer matches those runs, so they need status=None.

🏭 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	❌ 15/16 — pr-open-and-ready
Review findings	❌ not clean
Reviewer escalation	❌ Changes the default behaviour of a public client method (last_run()) that downstream code such as the Python SDK relies on, without marking it as breaking.
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

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 0bf14f56e · workflow run}

[apify-factory]

Important: Changing the default to SUCCEEDED silently breaks the common start() then last_run().get() / .wait_for_finish() / .iterate_dataset_items() pattern, because a READY or RUNNING run is no longer matched and callers get None or an older run; the Python SDK e2e test asserting the started run is READY/RUNNING fails, and so does this repo's tests/integration/test_run.py:536 (on a fresh Actor whose only run is still running, the iterator yields nothing) - this is a breaking change shipped as plain feat: without ! or a BREAKING CHANGE: footer. (apify-sdk-python tests/e2e/test_actor_api_helpers.py:129)

[apify-factory]

Note: the JS client's lastRun(options = {}) sends no status filter by default for both Actors and tasks, so with this default the same call returns different runs in the two clients. (apify-client-js src/resource_clients/actor.ts:509)

[Pijukatel]

Testing the AI review. Seems ok.