[vdusek]

Adds abort_with_parent to Actor.start, Actor.call, Actor.start_task and Actor.call_task. It's off by default and needs run_name. The flag is stored in the name's record under __ACTOR_CHILD_RUNS, so a parent that migrated or was resurrected still knows which children to abort.

When the parent is gracefully aborted, an SDK-internal ABORTING listener sends a graceful abort to every flagged child in parallel. off() can't remove this listener. Each child is aborted with the client that started it. A failed abort is logged and doesn't stop the others. Once the parent is aborting, a named start with abort_with_parent=True raises RuntimeError.

Hard aborts, timeouts and OOM kills don't abort the children. That would need a parent/child link on the platform.

Closes: #1128

✍️ Drafted by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.25%. Comparing base (ce98c84) to head (226b460).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1153      +/-   ##
==========================================
+ Coverage   93.09%   93.25%   +0.15%     
==========================================
  Files          54       54              
  Lines        3708     3766      +58     
==========================================
+ Hits         3452     3512      +60     
+ Misses        256      254       -2     

Flag	Coverage Δ
e2e	31.51% <22.66%> (-0.07%)	⬇️
integration	51.40% <40.00%> (-0.43%)	⬇️
unit	90.09% <100.00%> (+0.20%)	⬆️

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.

[Mantisus]

From Claude. Could you check that, pls?

Children started after ABORTING are never aborted. abort_runs_with_parent runs once. A named start or resurrect after that isn't covered. A typical orchestrator loop hits this:

for i, batch in enumerate(batches):
    await Actor.call(actor_id, batch, run_name=f'batch-{i}', abort_with_parent=True)

On a graceful abort, the current child is aborted and call returns ABORTED. The loop then starts the next batch inside the 30 s grace period. Once the parent is force-killed, that child is orphaned. A later call under an existing name can also resurrect the child we just aborted, since the registry resurrects ABORTED runs. I reproduced the first case in a unit test: after emit(ABORTING), a new named start with abort_with_parent=True never gets aborted.

Suggestion: set a "parent aborting" flag in abort_runs_with_parent. After that, find_or_start with abort_with_parent=True shouldn't start or resurrect runs. It could raise, or abort the run right after recording it. A test for this case would help too.

[vdusek]

continue here after #1184

[barjin]

Thank you @vdusek , just one nit regarding the used methods.

The logic looks sound to me 👍 approving

[apify-approval-mirror]

Mirroring approval from @Mantisus.

[vdusek]

Let's wait for the JS counterpart. I'm also not 100% sure about the internal listeners, though there may not be a much better option.