-
Notifications
You must be signed in to change notification settings - Fork 493
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
simulate: resource population #6015
base: master
Are you sure you want to change the base?
Conversation
466fd50
to
5ba0a9a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6015 +/- ##
==========================================
+ Coverage 51.79% 51.97% +0.18%
==========================================
Files 644 644
Lines 86511 86919 +408
==========================================
+ Hits 44805 45175 +370
- Misses 38834 38870 +36
- Partials 2872 2874 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
I believe all comments have been addressed at this point and test coverage is near 100%. The only problem is I'm still occasionally getting |
Fixed in 791df53. See body for details |
This was initially missed because the e2e test did not use the extra resource arrays and coverage was easy to overlook because we don't actually get handler coverage info for e2e tests (because they are e2e and the test itself goes through libgoal)
The failing CI was from the non-deterministic behavior of the population algorithm. Turns out the From the body of fd2c8dc: The initial reason for desiring this was because of the non-deterministic behavior of maps made testing difficult. When thinking about it more, I realized that having deterministic population will also improve the developer experience since the same txn group will always get back the same populated resources. This change, however, does expose a potential problem inherit to resource population: order matters. As seen in the modified test, the determinstic order results in an extra resource in the extra resource array. In the future steps could be taken to try to improve the efficiency, but unless we go over every permutation of resource ordering there will always be cases where algorithmic population will not result in the most efficient resource packing. |
5657d49
to
06549f5
Compare
The inital reason for desiring this was because of the non-deterministic behavior of maps made testing difficult. When thinking about it more, I realized that having deterministic population will also improve the developer experience since the same txn group will always get back the same populated resources. This change, however, does expose a potential problem inherit to resource population: order matters. As seen in the modified test, the determinstic order results in an extra resource in the extra resource array. In the future steps could be taken to try to improve the efficiency, but unless we go over every permutation of resource ordering there will always be cases where algorithmic population will not result in the most efficient resource packing.
a49a709
to
fd2c8dc
Compare
Relevant issue #5616 |
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.
LGTM, some minor suggestions/questions.
@joe-p could you fix the reviewdog and respond to the review? |
Co-authored-by: Pavel Zbitskiy <[email protected]>
Co-authored-by: Pavel Zbitskiy <[email protected]>
Re-triggered test run passing |
Summary
When a user calls simulate with
UnnamedResources
enabled, simulate should suggest to the user how they can populate the resource arrays in their transactions to properly send the transaction group to the network.Test Plan
/simulate
endpoint with ResourcePopulator functionalityledger/simulation/resources.go
coverage