dagster
dagster copied to clipboard
dagster-io
Add special logic to interpret solid selection as op selection for querying runs.
Until https://github.com/dagster-io/dagster/pull/9280 lands, we have been writing selection tags as solid_selection instead of op_selection. We want to be able to filter runs s.t. when searching for the op_selection tag, historic runs which still stored using the solid_selection tag, show up.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Ignored Deployments
| Name | Status | Preview | Comments | Updated |
|---|---|---|---|---|
| dagit-storybook | ⬜️ Ignored (Inspect) | Aug 10, 2022 at 6:53PM (UTC) | ||
| dagster | ⬜️ Ignored (Inspect) | Aug 10, 2022 at 6:53PM (UTC) | ||
| dagster-oss-cloud-consolidated | ⬜️ Ignored (Inspect) | Aug 10, 2022 at 6:53PM (UTC) |
![vercel[bot] avatar](https://avatars.githubusercontent.com/in/8329?v=4 "Published by a pub.dev verified publisher"){kind=small}
@prha I assumed we wouldn't be comfortable with inducing a data migration, but I guess since the functionality is pretty niche, it's probably OK? How would we communicate to users that a data migration is required for the feature?
We have data migrations which will run when users run dagster instance migrate. We can just put something in the release notes saying that if they see something odd when they search for runs with op selections (e.g. missing runs), they can run dagster instance migrate.
The functionality degrades nicely, in that if they do nothing, maybe some run views look wrong, but it'll only be old runs (new runs should have the proper tags).
Right - was just wondering if we'd want to do anything more in terms of telling users "hey you have runs whose tags might need to be migrated - or something but that makes sense to me.