Yeah, I think this makes sense.
Thu, Jun 17
returning for queue management
Would feel more comfortable with this being EventLogRecord (as per the discussion in D8422)
Wed, Jun 16
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.
Tue, Jun 15
I think this looks good, but now just concerned about whether we can land this without announcing a breaking change. It's a pretty trivial transform (codemod), but we will break folks who are using typing for their evaluation function signatures.
Mon, Jun 14
+1 on moving way from ExecutionContext.
Fri, Jun 11
This isn't the cleanest solution, because it requires a bunch of manual resolving, but I don't think there's a better way of building up this mapping.
add mapping from dagster version => alembic version on a per-storage basis
Thu, Jun 10
We talked about this a bit offline. I think this is right. The partition space doesn't make much sense independent of the pipeline, in that it provides the config for a pipeline execution which must be mode-aware.
Oh, I have an idea of how to do this mapping....
add backcompat tests for resetting all snapshots and reapplying
The specific migration revision is a bit tricky, because you could have three different physical dbs for the different storages, all with a different alembic version.
Wed, Jun 9
@dish were you able to repro the laggy behavior before?
Tue, Jun 8
going to abandon in favor of a new ProcessLogManager API or something similar.
mostly nits... biggest question is around the term "Reacted Runs". Just catching up to the latest thinking on it.
Fri, May 28
Thu, May 27
@dgibson I think unrelated... digging into that right now.
Wed, May 26
I have a somewhat averse reaction to do_X function names.
I think need this same logic in AssetMaterializations.tsx.
Tue, May 25
I think technically this is a breaking change, but I think it's okay because it's not publicly documented anywhere and only used internally since 0.11.8
switch to more terse internal namedtuple representation (thanks @sandyryza)