You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8d326be
Browse filesBrowse the repository at this point in the historyBrowse files
Resolve live producers by region and read their XCom by attempt
Once a loop body or a mapped region can hold several live task instances with
the same task_id and map_index, a consumer can no longer find its producer from
(dag_id, run_id, task_id, map_index) alone, so the lookup has to know where the
caller sits: in the same iteration, in the previous one (what a loop body means
by "the last result"), outside the loop, or in an explicitly named region. When
more than one live candidate still fits we have no sensible option to raise
an error.
Only live (non-archived or superceded) try are candidates, and their data is
read by UUID. An archived try keeps its XCom under its own UUID, so reading by
the resolved try is exact and cannot revive data from work a clear replaced.
Callers that predate regions must see what they saw before, so the default read
scope stays the sentinel region and regional rows appear only when a caller asks
for them. Lookups of earlier runs refuse a non-sentinel region because a region
belongs to a single Dag run, so the producer has to be resolved again for each
run.
The scheduler detected changes to upstream state and tracked map-length
revisions by TaskInstanceKey, which cannot tell two regions apart. One region's
expansion would have marked another's as changed, so both now key on the attempt
and on (task, region).
0 commit comments