-
Notifications
You must be signed in to change notification settings - Fork 22
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(blockifier): inject VC into CallInfo::summarize #2122
refactor(blockifier): inject VC into CallInfo::summarize #2122
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Artifacts upload triggered. View details here |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2122 +/- ##
===========================================
+ Coverage 40.10% 69.38% +29.28%
===========================================
Files 26 108 +82
Lines 1895 13984 +12089
Branches 1895 13984 +12089
===========================================
+ Hits 760 9703 +8943
- Misses 1100 3874 +2774
- Partials 35 407 +372 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
7a27e86
to
65e10b3
Compare
179fe8c
to
a9e2006
Compare
Artifacts upload triggered. View details here |
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 suggest a cleaner approach - don't pass the VC.
Summarize regularly, and if the flag is on, drop the event summary and calc it again on validate & execute call infos.
Also, this should not affect the bouncer.
Reviewable status: 0 of 10 files reviewed, all discussions resolved (waiting on @aner-starkware)
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.
- why is this cleaner? replacing an already-calculated object with another seems jumbled
- this will have no effect on the bouncer because this will have no effect on post-0.13.1 blocks; you are saying, it is worth adding code to ensure the 0.13.1 bouncer still gets "correct" event counting, and only the fee computation should be effected?
Reviewable status: 0 of 10 files reviewed, all discussions resolved (waiting on @aner-starkware)
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.
- No, I say, if we don't pass the VC, you don't need to fix the calc for the bouncer, just for the fee calc.
- It is more local and framed. Doesn't require passing another argument to many places just for this. I prefer not to have this hack in call_info.summarize()
Reviewable status: 0 of 10 files reviewed, all discussions resolved (waiting on @aner-starkware)
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 TransactionResources
struct doesn't store call infos. I would need to compute the "alternative" event resources when computing the resources, and then choose what to charge for in to_gas_vector.
injecting call infos as a dependency of resource computation seems like a worse option; did you have some specific place in mind where it makes sense to recompute?
Reviewable status: 0 of 10 files reviewed, all discussions resolved (waiting on @aner-starkware)
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.
No, I say, if we don't pass the VC, you don't need to fix the calc for the bouncer, just for the fee calc.
why would we want to fix this for the bouncer at all? bouncer is irrelevant for reexecution, and we should not support "no inner event charge" mode in latest sequencer version, right?
It is more local and framed. Doesn't require passing another argument to many places just for this.
where would we get the callinfos from...? (above question)
Reviewable status: 0 of 10 files reviewed, all discussions resolved (waiting on @aner-starkware)
65e10b3
to
975ff5a
Compare
a9e2006
to
d525dc2
Compare
Artifacts upload triggered. View details here |
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.
Reviewed 4 of 10 files at r1, 6 of 6 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @aner-starkware)
d525dc2
to
70bfbca
Compare
Artifacts upload triggered. View details here |
Artifacts upload triggered. View details here |
No description provided.