-
Notifications
You must be signed in to change notification settings - Fork 61
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
RequiredNamespaces return by dapps is not well managed [code: 5102] #230
Comments
When you have same network on both (dapp and my wallet) i'm getting this errors : SessionProposalErrorEvent(id: 1701784882276298, requiredNamespaces: {eip155: RequiredNamespace(chains: [eip155:56], methods: [eth_sendTransaction, personal_sign], events: [chainChanged, accountsChanged])}, namespaces: {eip155: Namespace(accounts: [eip155:56:0xfc4124d107ac29e3b1638c335d768d54a8cf5700], methods: [personal_sign, eth_sendTransaction], events: [chainChanged])}, error: WalletConnectError(code: 5102, message: Unsupported events. onSessionProposeRequest namespaces events don't satisfy requiredNamespaces events for eip155. Requested: [chainChanged, accountsChanged], Supported: [chainChanged], data: null)) but approveSession got this configuration : await wcClient.approveSession( Is there a way to give it the default namespace before it even attempts to pair, because I have the impression that at times it blocks it. |
Hello @Fabrice-Fabio, I don't fully understand your issue but will try to help. First question I have is: are you developing a wallet or dapp?
I can see the wallet only supports dApp side:
Wallet side (onSessionProposalEvent):
Let me know if this helps. |
Hello @quetool first of all, thank you for the response. I was unaware that it was necessary to use “eventData.params.generatedNamespaces” instead of hard-coding the namespaces as indicated in the documentation.
I will better contextualize the problem for your understanding. Process In the normal process, it happens as follows:
And in the “_onSessionRequest()”, I display a modal with two buttons, namely “approve” and “cancel”.
Errors
The following error occurs even before the user approves or refuses, that is, it happens upon connection. So, I was wondering if there is a way to avoid this, maybe an initialization during... |
Thanks for the clarification! On one side we have the Wallet (you in this case) The way the protocol works, in regards of namespaces (chains + methods + events), is as follows: The wallet "register" handlers (for handling methods) and event emitters (for emitting events) for any chain the wallet developer wants to support. Which chains, which handlers and which emitters it's up to the wallet dev, could be just one, could be two, could be every EVM chain and this will determine which ones are approved during session proposal. Register handler example:
Register event emitter example:
You should do this for every chain, method and event you want to support on your wallet. Ok so now the dApp would propose a session by asking for required and optional namespaces during connection
and based on what the wallet supports (by registering or not handlers and emitters) a session request will be created along with a new set of Note: There's currently an issue with generatedNamespaces that we are taking care of but I don't think you are affected by this anyway. #205 So now my question would be: Are you (as wallet) registering an event emitter for |
Hello @quetool, thank you for your response. The background workings are now a bit clearer to me. Indeed, I've also noticed bug #205. When I used "eventData.params.generatedNamespaces!", it generally works well, but sometimes it returns "null". What I suggest, and I think this should solve the issue, is to continue performing the calculation and return what you currently return. However, wallet dev could also return a defaultNamespace that covers all cases in case something got wrong or if "generatedNamespaces" return null. P.S. In my case, I did something like this:
And I configured my "defaultNamespaces" myself. I had also made a PR (Pull Request) for the documentation in the meantime. If you could merge it, that would be great. I'll probably make another one this weekend that takes into account what we've discussed because, yes, it lacks quite a bit of information. Regarding my bug, I now understand better that one needs to have a registerEventEmitter() of each type for each supported network. I'll set that up and get back to you soon |
@Fabrice-Fabio I'm about to push the fix for #205 so your workaround won't be needed. About documentation PRs you can open them but I won't be able to check them any time soon. We are anyway aware of our lack of documentation Flutter-wise and updating them is in the roadmap, we are just focusing on some other big things. |
@Fabrice-Fabio in my explanation here I forgot to mention that Wallet should register the accounts as well in order to fully support a Namespace. Bottom line: To fully support a Namespace such as
you will need to register 3 things: an eventEmitter, a methodHandler and an account
|
Thanks it works. You're doing a good job. |
Use cases.
Connection from a uniswap or pancakeswap type dapp, the connection will work every other time.
Sometimes it returns an error which is caught by wcClient.onSessionProposalError.subscribe() in the format:
"SessionProposalErrorEvent(id: 1701782571459814, requiredNamespaces: {eip155: RequiredNamespace(chains: [eip155:137], methods: [eth_sendTransaction, personal_sign], events: [chainChanged, accountsChanged])}, namespaces: {eip155: Namespace(accounts: [ eip155:137:0xfc4124d107ac29e3b1638c335d768d54a8cf5700], methods: [personal_sign, eth_sendTransaction], events: [chainChanged])}, error: WalletConnectError(code: 5102, message: Unsupported events. onSessionProposeRequest namespaces events don't satisfy requiredNamespaces events for eip155.Requested: [chainChanged, accountsChanged], Supported: [chainChanged], data: null))"
While the app namespace is configured like this :
Which should logically take into account all cases.
Is there a way to avoid all of this?
Thanks
The text was updated successfully, but these errors were encountered: