-
Notifications
You must be signed in to change notification settings - Fork 48
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
Refactor execution module #5162
base: main
Are you sure you want to change the base?
Conversation
QA Wolf here! As you write new code it's important that your test coverage is keeping up. |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
5d8c6b7
to
1554b50
Compare
assert!( | ||
first.2.global.artifact_responses.len() < second.2.global.artifact_responses.len(), | ||
"Second should have all the artifact responses of the first, plus more. first={:?}, second={:?}", | ||
first.2.global.artifact_responses.len(), | ||
second.2.global.artifact_responses.len() |
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.
The assertion on the responses has been lost.
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.
what is going onnnn
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.
Yeah, that was deliberate - it did seemed like an implementation detail which shouldn't be visible externally and wouldn't fail unless the assertion which is preserved failed or there is an engine problem
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.
I added the assertion specifically because I had a bug in the initial draft implementation of the artifact graph where I wasn't correctly moving the responses to exec_state. They don't originate there. It works now. But we have very few tests for behavior across multiple executions where caching comes into play. If you want to delete it, go ahead, but it makes me nervous how few tests exercise this.
Signed-off-by: Nick Cameron <[email protected]>
Signed-off-by: Nick Cameron <[email protected]>
Signed-off-by: Nick Cameron <[email protected]>
Signed-off-by: Nick Cameron <[email protected]>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5162 +/- ##
==========================================
+ Coverage 85.95% 86.02% +0.07%
==========================================
Files 90 92 +2
Lines 32715 32716 +1
==========================================
+ Hits 28121 28145 +24
+ Misses 4594 4571 -23
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
I'm approving, but in case you weren't aware, we're trying to do a bug-fix-only release on Thursday this week (tomorrow) for demos next week. Any risky changes should wait until after the release to merge.
The goal was to breakup execution/mod.rs which is just too big, encapsulate caching, and generally tidy up starting execution given we have mock execution and caching with some kinda complicated interactions.