-
Notifications
You must be signed in to change notification settings - Fork 375
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
feat(pkg/std): ensure files are sorted in a MemPackage
#1618
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1618 +/- ##
==========================================
+ Coverage 44.79% 47.49% +2.70%
==========================================
Files 459 388 -71
Lines 67642 61304 -6338
==========================================
- Hits 30300 29117 -1183
+ Misses 34808 29749 -5059
+ Partials 2534 2438 -96 ☔ 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 think perhaps the only change necessary is to add something like this:
sort.Slice(
msg.Package.Files,
func(i, j int) bool {
return msg.Package.Files[i].Name < msg.Package.Files[j].Name
},
)
That should sort the package files in place as long as the original order doesn't need to be preserved, but I don't think it does.
I was thinking copy and replace versus altering in place for safety but this is a significantly more elegant solution. |
…' into feat/vm-sort-addpkg
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.
Looks good to me. One more thing to maybe consider -- this seems to be the correct way to sort strings, but does is the sorting exactly the same as what happens when go parses files? Probably. But how do we know for sure?
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 think to address your comment about ordering and doing a small performance improvement, too:
- Move the sorting into
std.MemPackage.Validate
(this will eventually be moved tosdk/vm
, per this comment discussed with Jae) - After sorting, change the current check for duplicates in
Validate()
(the one using a map) to a simpler one:
// NOTE: Before this, add assertion that MemPkg contains at least 1 file
prev := mempkg.Files[0].Name
for _, file := range mempkg.Files[1:] {
if prev == file.Name {
// return error
}
prev = file.Name
}
(The following works because the slice is sorted)
@thehowl Change to your suggestion or merge as is based on previous approvals? |
@waymobetta change it to mine, we get to kill two birds with one stone |
AddPackage
MemPackage
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 fixed up this PR to move it to validate that the files are sorted instead. This seems more coherent with the line of thought of Validate()
in general (ie. being readonly); rejecting unsorted MemPackage seems reasonable as there is currently no way to craft a MemPackage through official tools (like gnokey) where the filenames are not sorted.
I'll wait for another review, as my changes significantly change Jon's original work.
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.
Seems reasonable. If we start seeing transactions failing because of unsorted packages then we can take a look to see what's going on.
This PR ensures in
MemPackage.Validate
that the files that it is being passed are correctly sorted. This is called in many places, among which the VM keeper.Context:
It was discovered that during the add package process, gno files get processed in an unpredictable order.
This relates to the below related issue (#1482) regarding multiple
init
statements being allowed since theseinit
statements would potentially be processed in unknown order.Related: #1482
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description