Repository navigation
Named child runs that survive migration and resurrection #1127
Description
When an Actor migrates or is resurrected, the process restarts and every in-flight Actor.call is
lost. Nothing records which child runs were already started, so the restarted Actor starts them all
over again, paying twice and duplicating the work. A user cannot fix this from the outside, because
only the SDK sees the migration.
Proposal
An optional name on Actor.start / Actor.call:
run = await Actor.start('apify/web-scraper', run_input, name='scrape-eu')With a name, the SDK keeps a name → run ID map in the key-value store and reattaches to the
recorded run after a restart. A new run is started only when nothing is recorded under that name, or
the recorded one ended in a state that cannot be resumed.
Actor.use_state (src/apify/_actor.py:1429) already provides a KVS-backed dict that survives
migration, so the registry can be built on it.
Prior art
apify-orchestrator, which splits this into a tracker and a find-or-start step:
- persisted name → run map: https://github.com/apify-professional-services/apify-orchestrator/blob/ef8b1c3feb1e08ea94ac40e1a1a6970b9c456a95/src/run-tracker.ts
- reattach decision: https://github.com/apify-professional-services/apify-orchestrator/blob/ef8b1c3feb1e08ea94ac40e1a1a6970b9c456a95/src/clients/apify-client.ts#L143-L155
✍️ Drafted by Claude Code
Activity
B4nan commentedon Sep 22, 2026
Three things worth pinning down in the design, from comparing the orchestrator and the skill in apify/agent-skills#90:
use_statepersists on interval and onMIGRATING. A hard kill (OOM, timeout) betweenstartreturning and the next persist leaves an orphan child that gets started again after resurrection. The registry should write the name → run ID entry to the KVS synchronously afterstartreturns, not wait for the periodic persist. The full fix is an idempotency key on the run-start endpoint scoped to the parent run, which I'll raise with the platform team separately.READY/RUNNING→ attach,SUCCEEDED→ return as is,ABORTED/TIMED-OUT→ resurrect it (Actors are expected to be resumable, and it's cheaper than starting over),FAILED→ start a new run under the same name and keep the old one in history. The orchestrator restarts in all the non-OK cases; the skill asks for resurrection. I'd go with resurrect.AmbiguousRunRequestErrorwhen the same unnamed call happens twice in one process. Requiringnameavoids that class of surprise.feat: reattach named child runs after migration or resurrection (#1149)
vdusek commentedon Oct 9, 2026
resolved by #1149