Consume every queued asset event from concurrent mapped outlets - #71994
Closed
Vamsi-klu wants to merge 2 commits into
Closed
Consume every queued asset event from concurrent mapped outlets#71994Vamsi-klu wants to merge 2 commits into
Vamsi-klu wants to merge 2 commits into
Conversation
apache#70972 already consumes queued asset events by id, so concurrent mapped outlets no longer strand events behind a timestamp watermark. These tests lock that contract for mapped producers so a later consume-path change cannot silently drop events from triggering_asset_events. closes: apache#54659
The same-timestamp and AND cases only pinned consume if events were already queued by hand. Running mapped TIs through register/queue keeps those pins on the user path, including alias context lookup. closes: apache#54659
boring-cyborg
Bot
added
the
area:Scheduler
This was referenced Aug 23, 2026
Vamsi-klu
marked this pull request as ready for review
August 23, 2026 06:38
Vamsi-klu
commented
Aug 23, 2026
Contributor
Author
There was a problem hiding this comment.
Description review:
- closes: #54659 is correct.
- Tests-only is stated; no newsfragment is correct.
- Default batching in one tick is called out as intended, not a bug.
- Test names and the pytest command match the diff.
Ready for maintainer review.
Drafted-by: Cursor Grok 4.6 (no human review before posting)
Contributor
Author
|
The extra pull requests under This was referenced are leftover from an earlier draft of the description. I put those names in, then took them out. GitHub keeps the timeline row anyway. Nothing in this PR depends on them. The only real link is the issue this PR is meant to fix. Drafted-by: Cursor Grok 4.6 |
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
1 participant
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.
closes: #54659
GitHub still lists a few other pull requests under This was referenced. I named them in an early draft of this writeup and then deleted those lines. GitHub keeps the timeline row even after the text is gone. Those pull requests are not part of this change. The only real link is the issue this PR is meant to fix.
What I did
Tests only. Mapped producer
@task(outlets=[asset]).expand(...)succeeds, then one scheduler tick. Assert all N events land on the consumer run and intriggering_asset_events. No production change. No newsfragment.Why I did
Three mapped outlets were finishing together and the consumer only saw a subset in
triggering_asset_events. Consume-by-event-id is already on main. Existing tests still insert ADRQ by hand, so they never covered this emit path.How I did
Emit:
dag_maker.run_ti(..., map_index=N)→register_asset_changes_in_db.Consume:
SchedulerJobRunner._create_dagruns_for_dags.Context:
get_template_contextafter loadingconsumed_asset_events.One tick batches all visible events. That is the default, not a bug. Leftovers stay for the next tick.
What's the impact
None at runtime. If the mapped emit path regresses, these tests fail instead of silently dropping events.
What's the testing
airflow-core/tests/unit/jobs/test_scheduler_job.pytest_mapped_outlet_asset_events_consumed_in_one_ticktest_mapped_outlet_asset_events_consumed_across_staggered_tickstest_mapped_outlet_asset_events_same_timestamp_are_all_consumedtest_mapped_outlet_asset_events_and_condition_waits_for_all_assetstest_mapped_outlet_asset_alias_events_are_all_consumedWas generative AI tooling used to co-author this PR?
Generated-by: Grok 4.6 following the guidelines