hey, as we refactor more of our dagster code to use declarative scheduling patterns i’ve been using observable source assets a fair bit and have some feedback. previously, if we had tables in our data warehouse that were populated by some process outside of dagster, we'd create custom sensors to check when those tables were updated and kick off downstream jobs. instead we're now representing them as observable source assets, which seems like the recommended practice: • with sensors, we could check multiple tables in each evaluation, which meant that if the compute required was an

INFORMATION_SCHEMA

query to check when those tables were updated, we could check multiple tables in one query and yield any run requests needed. there isn't a way to do this with observation functions and it feels like we're missing some notion of an observable multi source asset? • observation functions being run as jobs feels a little unintuitive - i'm using them to tell me if the asset in question has changed and think of it as a background process that evaluates every few seconds along with typical sensor evaluations i like the benefit of then being able to use auto materializations for downstream assets but would like the process of "observing" a source asset to feel more lightweight

cc @Sean Lopp who has brought feedback related to this

@Prratek Ramchandani your experience matches mine, and we have an open issue to add observable multi-source assets. In the interim, this example shows how one job can check for multiple source asset updates: https://github.com/slopp/event_driven_dbt_assets @sandy I think Prratek phrases the idea that observations should be allowed in sensors even better than I did!

cc @sean

@sandy yeah that combined with a multi-asset option would be perfect

here's a couple issues for tracking: • https://github.com/dagster-io/dagster/issues/14103 • https://github.com/dagster-io/dagster/issues/13904