Once named child runs are tracked (#1127), the registry already knows every child and its state.
It should be readable.
Depends on #1127.
Proposal
runs = await Actor.child_runs()
# {'scrape-eu': RunInfo(run_id='abc123', status='RUNNING', started_at=...),
# 'scrape-us': RunInfo(run_id='def456', status='SUCCEEDED', started_at=...)}
That is enough for a caller to build their own progress reporting:
Counter(r.status for r in (await Actor.child_runs()).values())
# Counter({'RUNNING': 3, 'SUCCEEDED': 1, 'FAILED': 2})
One question this raises for #1127: whether the registry keeps a history per name. If scrape-eu
failed and was restarted under the same name, a report covering only the live run hides the failed
attempts. apify-orchestrator keeps both, in a failedHistory map alongside the current runs.
Out of scope
An on_update callback firing whenever a child changes status, which apify-orchestrator exposes as
UpdateCallback.
It would put a polling loop and an interval option inside the SDK, a callback cannot be persisted
across a migration the way the registry is, and the orchestrator needed a second callback for
item-count changes on top of the status one. A caller can poll Actor.child_runs() instead. Worth
revisiting if the SDK shares a single poll across all children, since that part a caller cannot do
from outside.
Prior art
✍️ Drafted by Claude Code
Once named child runs are tracked (#1127), the registry already knows every child and its state.
It should be readable.
Depends on #1127.
Proposal
That is enough for a caller to build their own progress reporting:
One question this raises for #1127: whether the registry keeps a history per name. If
scrape-eufailed and was restarted under the same name, a report covering only the live run hides the failed
attempts. apify-orchestrator keeps both, in a
failedHistorymap alongside the current runs.Out of scope
An
on_updatecallback firing whenever a child changes status, which apify-orchestrator exposes asUpdateCallback.It would put a polling loop and an interval option inside the SDK, a callback cannot be persisted
across a migration the way the registry is, and the orchestrator needed a second callback for
item-count changes on top of the status one. A caller can poll
Actor.child_runs()instead. Worthrevisiting if the SDK shares a single poll across all children, since that part a caller cannot do
from outside.
Prior art
RunTracker.getCurrentRunsRunInfo✍️ Drafted by Claude Code