feat: add request id to messageParams in @metamask/message-managers #4636
Conversation
| @@ -151,6 +151,7 @@ describe('DecryptMessageManager', () => { | |||
| throw new Error('"message" is falsy'); | |||
| } | |||
| expect(message.messageParams.from).toBe(messageParams.from); | |||
| expect(message.messageParams.requestId).toBe(originalRequest.id); | |||
There was a problem hiding this comment.
the requestId is not needed on decrypt or encrypt, but added for consistency
decrypt and encrypt are being deprecated
…teUnapprovedMessage
|
edit: Fixed coverage by adding a test for the setMessageStatus expected thrown error before:
|
…ageStatus throws error check
|
Hi, I wanted to give a quick heads-up that I'm prepping a release candidate that includes Edit: 193.0.0 had to be merged urgently, but I created a new release candidate for this PR here: #4646. |
|
Hi @MajorLift, thank you very much! That would be great. I can update you when this is merged |
There was a problem hiding this comment.
How would you feel about making addRequestToMessageParams and createUnapprovedMessage generic? This lets us narrow the return types of these methods, allowing us to get rid of the type assertions in TypedMessageManager.
This works because the type of messageParams is now inferred from the argument that it receives. Also, because of the generic constraint on MessageParams, an error will be raised if messageParams is not a subtype of AbstractMessageParams.
Co-authored-by: Jongsun Suh <jongsun.suh@icloud.com>
|
Awesome suggestion @MajorLift! Thank you. Applied the extended return types to the methods and used |
Explanation
Adding the request id to reference metric event fragments created from the createRPCMethodTrackingMiddleware in the client. See use-case here: MetaMask/metamask-extension#26597
References
Changelog
@metamask/message-managerChecklist