kaxil commented on PR #67902: URL: https://github.com/apache/airflow/pull/67902#issuecomment-4607441985
@jroachgolf84 good question, but I don't think a `BaseEventTrigger` writes the asset store at all, so this case doesn't really arise. The asset store holds producer-side state: a task's incremental watermark/cursor and the AIP-103 checkpointing state. That's authored by a task, which always has a TI. A watcher doesn't produce that. Its job is to detect an external event and fire an AssetEvent, and it delegates cursor/durability to the source it watches (SQS visibility, PubSub/Redis consumer offsets, Kafka offsets). Anything it carries with an event goes in the AssetEvent payload, not the store. So the writers are tasks (via the Execution API, recording `ti_id`) and the Core API PUT (an admin write with no task, recorded as NULL). The column is nullable with FK `ON DELETE SET NULL`, and the read routes outer-join `task_instance` and return `last_updated_by: null`, so that admin path is handled and isn't an error. Nothing writes the store from a trigger today afaik. If we ever do write asset state from the triggerer, it'd be from deferral triggers (a task that deferred), and those keep their task instance attached (`trigger.task_instance`), so they record a real `ti_id` just like the worker path. Watchers are the one trigger type with no TI, and also the one with no reason to write the store. So `last_updated_by_ti_id` as a TI FK is the right shape across all of it. -- 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]
