-
Notifications
You must be signed in to change notification settings - Fork 138
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 optional type ID ambiguity and migrate types #3272
Conversation
Cadence Benchstat comparisonThis branch with compared with the base branch onflow:master commit 052db5e Collapsed results for better readability
|
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.
Nice!
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.
Can you please also add a "Rehash test", similar to:
cadence/migrations/statictypes/intersection_type_migration_test.go
Lines 481 to 484 in 922e65c
// TestIntersectionTypeRehash stores a dictionary in storage, | |
// which has a key that is a type value with a restricted type that has two interface types, | |
// runs the migration, and ensures the dictionary is still usable | |
func TestIntersectionTypeRehash(t *testing.T) { |
The idea is to test, if there is an optional-typed TypeValue
is being used as a key in a dictionary, then retrieving (using the old hash/typeID) and updating that key during the migration should work.
I think |
hmm, yes it does (didn't realize it earlier). However, that test is for testing entitlements rehashing, and the optional-type seems more like a coincident/side-effect? It would be good to have a separate test for optionals, so that any change to the entitlement test won't accidentally remove the use of optional type. |
So while I was writing these tests, I realized that I am not actually sure the migration itself is strictly necessary. We had to migrated restricted/intersection and reference static types because how they are encoded and decoded from storage changed, but with optional types even though the TypeID itself is changing how it's printed, the encoding of these values is not changing. So any optional static types that were created and encoded with the old IDs are just going to be loaded from storage the same way, and there is no migration that actually needs to be performed on the data. I realized this while trying to write the test @SupunS was talking about above because I couldn't actually get the migration to run on the test data, as when the data was loaded from storage to be migrated, it was already "migrated" so to speak, in that it was already converted to the new format by virtue of having been decoded. Am I misunderstanding something about how this works, or do we just not need to do anything here? |
@dsainati1 Do you need help here with the rehash test case? I can finish this up |
If you have time that would be super helpful! Otherwise I can get to it after the security stuff |
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!
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3272 +/- ##
==========================================
+ Coverage 80.80% 80.81% +0.01%
==========================================
Files 380 381 +1
Lines 93643 93724 +81
==========================================
+ Hits 75666 75743 +77
- Misses 15276 15279 +3
- Partials 2701 2702 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@dsainati1 @SupunS Could you PTAL? |
Closes #3248
master
branchFiles changed
in the Github PR explorer