There was a bad decision-making process inside Sign Engine in regards of session requests where a wallet could use methods handlers AND onSessionRequest events but not separately.
The data carried by both logics didn't change, method handler will still make use of topic and parameters and onSessionRequest event will still make use of SessionRequestEvent object which contains id, topic, method, chainId and params but by fixing the decision-making logic inside Sign Engine we now resolve this issue https://github.com/WalletConnect/WalletConnectFlutterV2/issues/258
APPROVE SESSIONS:
BEFORE PR:
Until now, most developers were relying on generatedNamespaces object inside of SessionProposalEvent's params, which is a handy object that determines automatically which methods are supported based on which handlers are registered with registerRequestHandler()
AFTER PR:
Now, generatedNamespaces is still a valid object to be used to approve a session but if the wallet developer wants to handle session requests using onSessionRequest events (without registering a handler) then they will need to pass to approveSession() a custom set of namespaces that would include those methods without a registered handler. (This is similar to any other SDK)
HANDLING SESSION REQUESTS:
BEFORE PR:
Until now, only by registering request handlers was possible to handle a session (method) request and only after handling it with the registered handler, only then, an onSessionRequest event was emitted (which was useless since the request was already being responded at that point).
Furthermore, and more importantly, there was no way of handling the request with onSessionRequest since the onSessionRequest's event was being emitted only if a request handler was registered before and if a request handler was not registered for a given method then that method was considered unsupported. This is wrong!
AFTER PR:
Now, if a method handler is registered for a given method then that handler is going to be used to handle the request WITHOUT emitting an onSessionRequest event (which was anyway useless before, as mentioned above)
Now, if no method handler is registered for a given method, an onSessionRequest event will be emitted for that request and the request would have to be handled in the onSessionRequest subscription method. If there are no methods handlers registered then every request will emit an onSessionRequest event to be handled.
Description
There was a bad decision-making process inside Sign Engine in regards of session requests where a wallet could use methods handlers AND
onSessionRequestevents but not separately.The data carried by both logics didn't change, method handler will still make use of
topicandparametersandonSessionRequestevent will still make use ofSessionRequestEventobject which containsid,topic,method,chainIdandparamsbut by fixing the decision-making logic inside Sign Engine we now resolve this issue https://github.com/WalletConnect/WalletConnectFlutterV2/issues/258APPROVE SESSIONS:
BEFORE PR:
generatedNamespacesobject inside ofSessionProposalEvent's params, which is a handy object that determines automatically which methods are supported based on which handlers are registered withregisterRequestHandler()AFTER PR:
generatedNamespacesis still a valid object to be used to approve a session but if the wallet developer wants to handle session requests usingonSessionRequestevents (without registering a handler) then they will need to pass toapproveSession()a custom set of namespaces that would include those methods without a registered handler. (This is similar to any other SDK)HANDLING SESSION REQUESTS:
BEFORE PR:
onSessionRequestevent was emitted (which was useless since the request was already being responded at that point).onSessionRequestsince theonSessionRequest's event was being emitted only if a request handler was registered before and if a request handler was not registered for a given method then that method was considered unsupported. This is wrong!AFTER PR:
onSessionRequestevent (which was anyway useless before, as mentioned above)onSessionRequestevent will be emitted for that request and the request would have to be handled in theonSessionRequestsubscription method. If there are no methods handlers registered then every request will emit anonSessionRequestevent to be handled.How Has This Been Tested?
Due Dilligence