Pass task/asset scopes to serialize methods instead of ti_id/asset_ref#68274
Merged
amoghrajesh merged 5 commits intoJun 10, 2026
Merged
Conversation
Lee-W
reviewed
Jun 9, 2026
1 task
Lee-W
reviewed
Jun 9, 2026
Lee-W
reviewed
Jun 9, 2026
Lee-W
approved these changes
Jun 9, 2026
Contributor
Author
|
Failures are unrelated: |
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
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.
Was generative AI tooling used to co-author this PR?
What
Related to #66859
serialize_task_store_to_refandserialize_asset_store_to_refonBaseStoreBackendpreviously receivedti_id: str(a UUID) andasset_ref: strrespectively. A newti_idis issued on every task retry, so any object storage path derived from it would be different per retry, that means that a job ID written by try 1 would be unreachable by try 2 when a backend tries to reconnect to an existing external job (the primary use case for a custom backend, e.g.ResumableJobMixin).Current behaviour
serialize_task_store_to_refreceives a UUID (ti_id) that changes each retry. A custom backend deriving its storage path fromti_idproduces a different path per retry, orphaning values written by previous tries. Similarly,serialize_asset_store_to_refreceives a plain string (asset_ref) that loses the distinction between name and URI.Proposed change
Both methods now receive a scope object -
TaskScope(dag_id, run_id, task_id, map_index) for the task variant andAssetScope(name, uri) for the asset variant.The scope is stable across retries for the same logical task instance, so a custom backend can derive a deterministic, retry-stable path. The
AssetScopechange also lets backends correctly distinguish name vs URI when constructing paths.context.pycall sites updated to passself._scope(task) andAssetScope(name=..., uri=...)(asset) instead of the previous string values.Testing
Check in the diff, InMemoryStoreBackend is an implementation
InMemoryStoreBackendintest_context.pyto implement the new signatures, constructing amem://dag/run/task/map_index/keypath from the fullTaskScopematching the structure a real object storage backend would use.{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.