Hey, ran into this while reading through the new wallet-sdk messenger.
When a bridge is created with waitForReady: true (which is what the iframe transport does), send() hands you back an envelope { id } right away, but the message that actually goes out on the wire ends up with a different id. So the id you were given never matches the id the peer sees.
It's in bridge() in packages/wallet-sdk/src/core/Messenger.ts. The deferred branch generates an id for the return value, then once readyPromise resolves it calls to.send(topic, payload, dest) again, and fromWindow's send mints its own fresh uuid for the envelope. The comment sitting right above that line even says "Re-send with the same id so request/response correlation holds", so keeping the id is clearly the intent, it just doesn't happen.
This doesn't break the current EIP-1193 flow, since that correlates on the JSON-RPC request id inside the payload rather than the envelope id. But the messenger exposes on(topic, listener, id) for correlating by envelope id, and that can't ever match for these sends because the id on the wire isn't the one send() returned.
Repro in jsdom: bridge two fromWindow messengers with waitForReady: true, call send() before the peer is ready, then dispatch the ready message, and compare the id you got back against the envelope that lands in postMessage. They're different.
Happy to put up a PR for it.
Hey, ran into this while reading through the new
wallet-sdkmessenger.When a bridge is created with
waitForReady: true(which is what the iframe transport does),send()hands you back an envelope{ id }right away, but the message that actually goes out on the wire ends up with a different id. So the id you were given never matches the id the peer sees.It's in
bridge()inpackages/wallet-sdk/src/core/Messenger.ts. The deferred branch generates an id for the return value, then oncereadyPromiseresolves it callsto.send(topic, payload, dest)again, andfromWindow'ssendmints its own fresh uuid for the envelope. The comment sitting right above that line even says "Re-send with the same id so request/response correlation holds", so keeping the id is clearly the intent, it just doesn't happen.This doesn't break the current EIP-1193 flow, since that correlates on the JSON-RPC request id inside the payload rather than the envelope id. But the messenger exposes
on(topic, listener, id)for correlating by envelope id, and that can't ever match for these sends because the id on the wire isn't the onesend()returned.Repro in jsdom: bridge two
fromWindowmessengers withwaitForReady: true, callsend()before the peer is ready, then dispatch thereadymessage, and compare the id you got back against the envelope that lands inpostMessage. They're different.Happy to put up a PR for it.