Repository navigation
feat: reattach named child runs after migration or resurrection - #1149
Merged
Merged
Conversation
vdusek
added
the
t-tooling
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1149 +/- ##
==========================================
+ Coverage 92.90% 93.16% +0.26%
==========================================
Files 53 54 +1
Lines 3566 3702 +136
==========================================
+ Hits 3313 3449 +136
Misses 253 253
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
vdusek
added this pull request to stack #1152
September 30, 2026 07:49
vdusek
force-pushed
the
feat/named-child-runs
branch
from
October 6, 2026 13:20
82366a3 to
8e76335
Compare
vdusek
marked this pull request as ready for review
October 6, 2026 13:33
apify-service-account
added
the
tested
Closed
Contributor
Author
|
TODO:
✍️ Drafted by Claude Code |
Mantisus
reviewed
Oct 7, 2026
# Conflicts: # src/apify/_actor.py
… name to its input
![apify-approval-mirror[bot]](https://avatars.githubusercontent.com/u/24586296?s=60&v=4){kind=small}
# Conflicts: # src/apify/_actor.py
Pijukatel
approved these changes
Oct 9, 2026
vdusek
added a commit
that referenced
this pull request
Oct 9, 2026
`Actor.child_runs` is a sync property that maps each run name to a `RunClientAsync` for the current run under that name. It has the same shape as `Actor.childRuns` in the JS SDK (apify/apify-sdk-js#759). The client covers the run and its storages: ```python run = await Actor.child_runs['scrape-eu'].wait_for_finish() ``` The SDK reads the registry from the default key-value store when the Actor initializes, so runs recorded before a migration or resurrection are included and reading the property makes no API calls. That adds one record read to every init. A malformed record fails the init and leaves the Actor uninitialized. Runs started without a `run_name` aren't tracked. Runs that were replaced under a name stay in the `history` of the `__ACTOR_CHILD_RUNS` record and aren't exposed. A run started or reattached with a custom `token` gets a client with that token. A run recorded before a migration and not reattached since gets the default client, because the token isn't stored. It also fixes a duplicate `max_items` deprecation warning from #1149: a named start that resurrects its recorded run no longer warns a second time from inside the SDK. Docs are in #1160. Closes: #1129 *✍️ Drafted by Claude Code*
vdusek
added a commit
that referenced
this pull request
Oct 15, 2026
Follow-up to #1149 and #1151 that aligns named child runs with the final version of apify/apify-sdk-js#759. Changes: - A different Actor, task or input under an existing `run_name` raises a `ValueError` only when the recorded run would be reused (reattached, returned as `SUCCEEDED`, or resurrected). When the recorded run `FAILED` or is gone, a new run starts with the new request, the old run moves to `history`, and the record takes the new checksum ([agreed here](apify/apify-sdk-js#759 (comment))). - The client of a named run is stored only after the run is started or reused. - The `run_name` docstrings describe the new rule. No action on [B4nan's comment](apify/apify-sdk-js#759 (comment)) about loading the child-run record lazily instead of in Actor init. JS kept the load in `init()`, because the synchronous `Actor.childRuns` getter needs the records, and Python already loads them the same way in `__aenter__`. The docs in #1160 still say a name is bound to its first input. That will be fixed there. *✍️ Drafted by Claude Code*
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Actor.start,Actor.call,Actor.start_taskandActor.call_taskaccept an optionalrun_name. Right after the child starts, the SDK records it in the default key-value store under__ACTOR_CHILD_RUNS. After a migration or resurrection of the parent, the same call finds the recorded run and reuses it:READY/RUNNING: reattaches to itSUCCEEDED: returns it as isABORTED/TIMED-OUT: resurrects it with the call's build, memory, timeout,max_itemsand max charge (anABORTING/TIMING-OUTrun is waited for first)FAILED, or the run no longer exists: starts a new run and moves the old one tohistoryThe record has the same shape as in the JS SDK (apify/apify-sdk-js#759):
runId,status,startedAt,checksumandhistory. The checksum covers the Actor or task ID and the input, computed the same way as in JS. Reusing a name for a different Actor, task or input raisesValueError. Concurrent calls under one name in the same process share a single run.A named
callon a reattached or resurrected run streams only new log lines. If the API reports a recorded run as missing, the SDK retries for 3 seconds before replacing it, because a run started moments ago may not be on every API replica yet.A hard kill between the platform starting the child and the registry write can still orphan the child. Closing that gap needs an idempotency key on the run-start endpoint.
Closes: #1127
✍️ Drafted by Claude Code