-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[FA] get rid of migration flag #15269
base: main
Are you sure you want to change the base?
Conversation
⏱️ 1h 16m total CI duration on this PR
🚨 1 job on the last run was significantly faster/slower than expected
|
9c614c4
to
77a70c2
Compare
77a70c2
to
e9d3ee5
Compare
daea913
to
0e82d73
Compare
0e82d73
to
23a5985
Compare
fbf3e00
to
85e784a
Compare
@@ -208,7 +208,7 @@ async fn test_module_events() { | |||
== "0x0" | |||
}) | |||
.collect::<Vec<_>>(); | |||
assert_eq!(events.len(), 8); |
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 hate these obscure tests.
can you improve the test and change it to have a list of 9 events we expect, and then assert those?
that way, a next time things change - it's obvious why.
i.e. same thing as I did here - #15109
@@ -45,7 +45,7 @@ fn test_module_event_enabled() { | |||
vec![bcs::to_bytes(&10u64).unwrap()], | |||
); | |||
let events = h.get_events(); | |||
assert_eq!(events.len(), 13); |
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.
same as above, let's have a list of event types we expect (not the values)
aptos-move/e2e-tests/src/executor.rs
Outdated
@@ -554,6 +556,14 @@ impl FakeExecutor { | |||
self.read_apt_coin_store_resource_at_address(account.address()) | |||
} | |||
|
|||
/// Reads the CoinStore resource value for an account from this executor's data store. |
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.
wrong comment
We decided to ignore sharding tests in this PR and have a subsequent PR to address them
31c576a
to
f983046
Compare
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.
cc @davidiw on deprecating MigrationFlag. Basically the only change is making it such that if someone has APT PFS, and someone sends them APT coins:
- previously it would abort
- now it would be deposited to PFS
If they have both CoinStore and PFS, it will go to CoinStore.
@lightmark - address comments inside
@@ -826,11 +829,13 @@ module aptos_framework::coin { | |||
account_address: address, | |||
metadata: Object<Metadata> | |||
): bool { |
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.
let's rename this function from migrated_primary_fungible_store_exists
to can_receive_paired_fungible_asset
also then new_accounts_default_to_fa_apt_store_enabled is not really gating just apt, but also other paired coins, which seems a bit odd. maybe it should be
(features::new_accounts_default_to_fa_apt_store_enabled() && object:address(metadata) == 0xa) || ...
but I don't know what should be the default for other coins.
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.
inconsistent behavior will only make things more complicated. If we do this only for apt. The other coin has to register, that's so complicated.
When we enable this, most Dapp and CEX should support APT coin + FA. So they should as well do that for other coins they supported. It is just adding an entry to a mapping. But yeah, let's do another AIP and feature to migrate other coins.
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.
sounds good for the second part.
for the first - let's rename this function from migrated_primary_fungible_store_exists
to can_receive_paired_fungible_asset
edf8645
to
9e63f8d
Compare
9e63f8d
to
e181a8d
Compare
Description
MigrationFlag
.How Has This Been Tested?
ut
Key Areas to Review
Type of Change
Which Components or Systems Does This Change Impact?
Checklist