Should we throw in this case? This should be unreachable, if I understand this correctly.

one of the reasons I have this is because calling write postMessage/websocket/portStream doesn't fire data on its own stream, but my testStream does and ends up here.

I played around with this today but didn't quite manage to get it to work. We can improve this later if we get around to it - I don't see any reason to block on it.

Similarly, we might want to throw here. I'm guessing that it is possible we'll hit this case, if we every reply twice for any reason. But if we're doing that, it would be a bug that we'd want to track down.

This could happen if you made 2 instance of this class. One of them would try to handle an id it doesn't care about.

That would still be a bug, wouldn't it? At least I can't think of a case where this would be expected. Even if there were two instances, hopefully they'd be handling different sets of requests, i.e. we wouldn't have a request from one reply to the other.

const client1 = metaRPCClientFactory(connectionStream);
client1.bar();
// random id: 123456

const client2 = metaRPCClientFactory(connectionStream);
client2.baz();
// random id: 54321

in this example, by calling baz() on client2 would still get a result over connectionStream triggering onResponse on client1 which then would look for a callback (54321) it doesn't care about.

Ohhhhhh I see, I get it now. Thanks, I didn't realize this would broadcast each reply to all clients.

Is that how our post message stream works? 🤔

adding error handling to a couple places here. could be the source of some uncaught errors?