-
Notifications
You must be signed in to change notification settings - Fork 9
fix!: Runs should trigger materialization result #50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix!: Runs should trigger materialization result #50
Conversation
A bug was found that if a plan was empty. Also adds more metadata for each asset
e371e61 to
863ebac
Compare
| if model_name_for_notification in self._non_model_names: | ||
| self._current_index += 1 | ||
| self.logger.debug( | ||
| f"skipping non-model snapshot {model_name_for_notification}" | ||
| ) | ||
| continue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this the bug?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh. Sadly the bug was a bit multi-faceted.
This was part of the issue, but generally, the bug was that we created a queue of things to be reported as materialized. We did this because if you enable subsetting of the dagster asset you need to avoid out of order AssetMaterialization objects being yielded from the asset. So the logic to initialize that set of things was all funky. The core of the problems were in the Materialization tracker, which maybe could require further rethinking, but I think we now get a fuller picture of what's happening with these changes.
First part of opensource-observer/oso#4757
The follow on would be to update the dependency in the oso repo.