Malformed response from Lens transactions #469
Description
Hello,
While porting the Quidli frame for FC into Lens, I've found that once a transaction is performed properly, I don't receive a TxHash in the response. Actually, the response seems to be malformed in some way and the target frame of the post action can't load at all.
@defispartan made a fix in this demo code that works fine when the frame is anonymous. In that case, the response looks good and I find a TxHash in it, but setting Lens as the client automatically makes it fail.
As he suggested, there might be some issue in the framesjs debugger. I can't be more specific as I have no idea where the issue could be, but would be nice to have some information and eventually a fix.
Thanks
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
Participants
Activity
michalkvasnicak commentedon Aug 7, 2024
@lusorio I don't see also open frames support for lens here https://github.com/Quidli/debug-frames-lens/blob/366ca0043f2167545257023183f90359ebb08638/app/frames/frames.ts#L16-L32 have you tried setting up the middleware to handle Lens? See https://framesjs.org/guides/lens#create-your-frames-app
michalkvasnicak commentedon Aug 7, 2024
Another issue I found is in Lens support @defispartan implemented. I don't see any mention of
transactionIdthere so that could probably be the culprit.Here
transactionIdis missingframes.js/packages/frames.js/src/lens/index.ts
Lines 74 to 85 in 4df7a3a
Also it is not specified in the type definition
frames.js/packages/frames.js/src/lens/index.ts
Lines 10 to 28 in 4df7a3a
I thought that maybe it is just a matter of adding few lines, but then I noticed that
@lens-protocol/clientdoesn't havetransactionIdspecified inFrameEip712Requesttype. See the screenshotI tried to upgrade the
@lens-protocol/clientto2.3.1but with no help.@defispartan:
transactionIda part of the message?@lens-protocol/clientthat can be imported instead ofLensFrameRequestso we can be sure it comes from source of truth? For example XMTP is exporting the type from validator, seeframes.js/packages/frames.js/src/xmtp/index.ts
Line 2 in 4df7a3a
michalkvasnicak commentedon Aug 7, 2024
There is no mention of
transactionIdin Lens spec https://lensframes.xyz/#frame-requests but see Open Frames.Normally it would be just a matter of adding
transactionIdand use that in the middleware, but@lens-protocol/clientdoesn't havetransactionIdproperty support increateTypedData(). Lens useactionResponseinstead which breaks the compatibility with open frames.lusorio commentedon Aug 7, 2024
Hey @michalkvasnicak
Yes, you're right. The link I provided is the code @defispartan proposed to showcase the fix. Actually, when using an anonymous client I can fetch the tx hash (but then I'm missing the user's profileId). In the original code, I was using lens:1.0.0 or lens:vNext as a client as you can see here (with opposite result: profileId, but no tx hash)
Quidli/debug-frames-lens@fcb6b15#diff-b85d4cfafcd6e8f7267c4cfe49d28d8667f5965cf337f7d8d867c0404ad6fc25
michalkvasnicak commentedon Aug 8, 2024
@lusorio It is unfortunate but the issue is caused by lens not being 100% compatible with Open Frames spec. The difference is in
txbutton flow, when it is explicitly mentioned thattransactionIdshould be the part of the message payload, but Lens usesactionResponseinstead.defispartan commentedon Aug 8, 2024
This was done with the intention that
actionResponsecould be a more general field that supports transaction, signature, or relayer (Lens API) responses, but based on this thread, Open Frames plans to usetransactionIdfor signature responses as well, so we're going to update the Lens Frames spec to deprecateactionResponseand exclusively usetransactionId.After this change is made to the Lens spec and API/SDK, I can open a PR here to fix this.
lusorio commentedon Aug 9, 2024
Thank you both, I'll be waiting for it.