Open n13 opened 4 years ago
Indeed, with no error message in the app but logs: {"code":500,"message":"Internal Service Error","error":{"code":3050003,"name":"eosio_assert_message_exception","what":"eosio_assert_message assertion failure","details":[{"message":"assertion failure with message: Account already exists nellynelly12","file":"wasm_interface.cpp","line_number":964,"method":"eosio_assert"},{"message":"pending console output: ","file":"apply_context.cpp","line_number":113,"method":"exec_one"}]}}
I see you're already working on it Nik, but I'm curious. Is it a smart contract bug?
Weird. Need to check that
The thing is I need to fix the firebase deep links
It should work on contract but I know we are calling special actions
I think the solution on the contract level is to call the normal accept actions....
On May 23, 2020, at 10:29 PM, Pär Dahlberg notifications@github.com wrote:
Indeed, with no error message in the app but logs: {"code":500,"message":"Internal Service Error","error":{"code":3050003,"name":"eosio_assert_message_exception","what":"eosio_assert_message assertion failure","details":[{"message":"assertion failure with message: Account already exists nellynelly12","file":"wasm_interface.cpp","line_number":964,"method":"eosio_assert"},{"message":"pending console output: ","file":"apply_context.cpp","line_number":113,"method":"exec_one"}]}}
I see you're already working on it Nik, but I'm curious. Is it a smart contract bug?
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.
@n13 Is this still reproducible? If so how?
If somebody already has a Telos account, invite should still work
Ok here is some consideration:
On new account:
If a telos account already exists, then there are two possibilities
1 - That account belongs to someone else and is already taken 2 - That account is my existing Telos account
For (2) we need to import the user's private key and make them a Seeds account
For (1) we need to ask the user to choose a different account.
I am thinking on a UX level we should verify that we capture the private key before allowing them to use an existing telos account - we need to make sure it's actually their own account.
I think (2) is a complicated edge case we may not need to really spend all that much time on. On a contract level we can call acceptexist() and require signature to prove that this is actually their account.
(2) is "import private key" + accept invite merged into one. So in terms of UX we can probably kinda combine these and find a slick solution. But this only affects existing telos accounts, which is going to be a very rare case.