PR for issue #140 - Missing Wallet Query Interface in SDK to Retrieve Created Wallet Information

[johnnynanjiang]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[vietddude]

Approach is acceptable if we intentionally make CreateWallet idempotent, but this differs from issue #140’s requested query interface. Please document the new behavior and fix the e2e test so the second request must receive a new replayed result instead of reusing the first result from suite.keygenResults. Also consider hiding Badger-specific ErrKeyNotFound behind the KV abstraction.

[johnnynanjiang]

#140

Thanks for commenting @vietddude cc @anhthii

Shall we clarify if we like to go for this option

Ok we can consider store the Create wallet response in badger and then later on when create wallet with the same id , it should return the stored the response instead of returning "duplicate" error
#140 (comment) ?

If so, then this PR is implemented this way.

If not, then we could discuss further.

[vietddude]

Ok, I think this option is fine.

Before merging, you should fix the replay e2e test to ensure the second CreateWallet call actually receives a replayed result.

[johnnynanjiang]

Ok, I think this option is fine.

Before merging, you should fix the replay e2e test to ensure the second CreateWallet call actually receives a replayed result.

Is this what you referred to?

https://github.com/fystack/mpcium/pull/160/changes#diff-6720af2e42086e625d54e53e0ec0aca9234f226070454a9d6f25fea0661c0d19R82

[vietddude]

Yeah. Currently the second CreateWallet(walletID) can pass because suite.keygenResults[walletID] is already populated by the first call, so the test does not prove that a new replayed result was received.

Suggested direction:

• In e2e/keygen_test.go, split the helper into createWalletAndWaitResult(...) event.KeygenResultEvent.
• For the first call, store the returned result.
• For the second call, wait for a new result event from a fresh channel.
• Assert the replayed result has the same ECDSA/EdDSA pubkeys as the first result.

Something like:

first := createWalletAndWaitResult(t, suite, walletID)
replayed := createWalletAndWaitResult(t, suite, walletID)

require.Equal(t, first.ECDSAPubKey, replayed.ECDSAPubKey)
require.Equal(t, first.EDDSAPubKey, replayed.EDDSAPubKey)

[johnnynanjiang]

This part does that
https://github.com/fystack/mpcium/pull/160/changes#diff-6720af2e42086e625d54e53e0ec0aca9234f226070454a9d6f25fea0661c0d19R88

1. Create a new wallet with a new wallet ID
2. Create another new wallet with the same wallet ID in order to trigger replay
3. Make sure suite.keygenResults[result.WalletID] holds the result from the first wallet creation call in order to verify against the result from the second call
4. Reuse the verification logic in the test at line checkResults

Feel free to let me know if I miss anything or it doesn't make sense.