1fanwang commented on PR #71460:
URL: https://github.com/apache/airflow/pull/71460#issuecomment-5390963964
> Hey @1fanwang, sorry but I have second thoughts on this one. Could you
explain in human english the change here? Sorry but I find it difficult
recently to read these AI generated description. Can you really explain what
this change does? What does it allow? A before your PR vs after your PR would
help
hey @vincbeck my bad - we do NOT need this PR, and thanks for raising this!
I tried to walk through this again and repro, it proved me wrong and this
only breaks in a case that doesn't really come up in practice: a single DAG
waiting on two assets whose watchers are configured in the exact same way -
declared in the same DAG file
```
feed_us = Asset("feed_us", watchers=[AssetWatcher(name="w",
trigger=T(source="orders"))])
feed_eu = Asset("feed_eu", watchers=[AssetWatcher(name="w",
trigger=T(source="orders"))])
with DAG("combined_report", schedule=[feed_us, feed_eu]):
```
Airflow dedupes triggers within a single file parse, so both assets land on
one trigger row, and the trigger gets two accessors:
```
7 | feed_eu <- one trigger row, two assets
7 | feed_us
```
The watcher example in our docs assumes one accessor, so it raises and the
triggerer restarts it in a loop:
```
[error] Trigger ID 7 exited with error Task has 2 concrete inlets and outlets
[error] Trigger exited without sending an event. Dependent tasks will be
failed.
$ grep -c "concrete inlets and outlets" triggerer.log
16
```
Split across two DAG files it doesn't happen at all. Closing this and #71751.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
