Hello! We're trying out Assets and are psyched, but I was hoping to get some advice on how to best use them for our use case from any of you Dagsters. What we need is when a traditional op-based graph finishes, an asset-graph will materialize using the data created by the traditional graph. This asset graph is now a single asset but will become an asset DAG. What we did so far: 1. Declare a source asset which is the output of the traditional graph. 2. Create an IO manager to back that source asset. It can handle the output of the traditional graph and the input into the asset graph 3. Create a sensor which runs a

list-objects

to see if an output from the traditional graph is created, then creates a run request for the downstream asset graph. Our issues with this approach are (in order of priority): 1. Using list-object efficiently requires me to manage the S3 key partitions such that the operation will not be too expensive. As scale will rise I'll need to handle all sorts of issues. 2. Sensors are hard to use locally in development because they don't support resource configs, and don't integrate with the configured IO manager. It would make more sense for some process to ask the IO Manager about the outputs. 3. The somewhat awkward way that the output of the traditional graph becomes a source asset using some IO Manager hackery Any input on what's the best way to approach this will help a lot! Thanks 🙂 cc @Roei Jacobovich

you should be able to launch off an asset materialization using your traditional job, then use an asset sensor to kick off the materialization of downstream assets. This should save you from having to actually check for the physical asset in the sensor

Nice, I'll give it a shot, thanks