[kacpermuda]

Task loops (Airflow 3.4) and mapped tasks turn one task into many executions sharing the Dag, task and run ids. Building on #75132, each OpenLineage task event now tells which execution sent it, without querying Airflow:

• taskInstance: id, state, max_tries, dag_version_id and bundle, expanded_ti_count, region_id/region_index, and loop (iteration, rerun trajectory, gate decision).
• task: loop (the loop around the task, also from a task group inside it), task_group.unique_group_id, retry_delay.
• Job facet: per task loop_group, is_mapped, parse_time_mapped_count, trigger_rule, depends_on_past, retries; per group is_mapped, is_loop and the loop definition.

A FAIL the scheduler sends itself, e.g. after a worker died, is built without extra queries: from the task the scheduler holds, or from the task instance's region rows when that task comes from another Dag version. It shares the runId of the worker's START and carries the attempt's id (3.4+), state, map index, bundle and, for a task that isn't mapped, loop.index. expanded_ti_count and the loop run fields (loop.region_id, trajectory, fork fields) stay in worker events, as AirflowRunFacet.json describes. UI/API state changes still have no airflow facet.

Other changes consumers can notice:

• The scheduler's FAIL for a mapped task instance is now sent; reading the mapped operator's documentation fields used to fail it.
• That FAIL carries rendered_map_index only when the task renders one with map_index_template, as the worker's events do, instead of falling back to the map index.
• taskInstance.note is no longer sent: it only reached scheduler-sent FAILs, at the cost of a query on the scheduler's session.

The log link of a task instance in a loop is fixed in Airflow itself.

related: #75458

System tests check runId integrity by default, including invariants of loop events, and cover retries, rescheduled sensors, task states, and every task group / loop arrangement, also in the e2e suite.

---

Was generative AI tooling used to co-author this PR?

• Yes (Claude Code)

Generated-by: Claude Code (Opus 5.5) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {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.

🤖 Generated with Claude Code

[github-actions]

uv.lock on main just moved via #74290 ("Add AzureAISearchHook to the Microsoft Azure provider"), commit 935bac0 and this PR currently conflicts.

Quickest fix:

git fetch upstream main && git rebase upstream/main
rm uv.lock && uv lock
git add uv.lock && git rebase --continue
git push --force-with-lease

Automated nudge — ignore if you're not ready to rebase. This comment is updated in place on future uv.lock bumps.

[kacpermuda]

Finishing up last test fixes and additions, should be ready for re-review soon