Create a query-able asset sensor definition to fetch upstream assets nodes from pipeline
Overall, I like this direction, but I do think there are many cases where you might want to depend on multiple asset keys at once (the story_recommender pipeline is one example). This does add bits of complexity basically everywhere (need a fancier cursor object, and it's not obvious what exactly should be passed into the user's sensor function when just a single one of the many asset dependencies has been updated), but I do think that people will look for this functionality pretty quickly, and it would be nice to have a good story for them..
Yes, we'll have to provide a way to handle multi-asset sensors, but I think the guarantees provided by the single asset API are valuable enough that this should be pulled out separately.
We can provide an @multi_asset_sensor or something like that that has fewer guarantees around source run attribution.
Overall I am on board with this. It still needs docs etc. and I left a comment on one of the details of the API.
Would be good to add type annotations.
Thoughts on making source_run_ids an attribute of RunRequest? When I see "add_source_run_id" here, I'm not sure what entity it's getting added to.