Web Socket subscription drops initial messages

Hi @davesmith00000 👋🏽

I’ve been debugging all day (going crazy really 😄) a subtle issue with the Web Socket subscriptions and I now have a lead, but unfortunately not a fix yet.

As far I can observe, once a connection is established, there seems to be a delay in registering the subscription and so messages that arrive immediately are never processed by Tyrian, but they can be seen in the browser’s developer console.

I think the last version where this was working as expected was 0.3.2, so shame on me, I haven’t properly tested my application to find this issue sooner.

I tried to minimize the example using the Echo Server from the examples. For example, there is a message saying “Connection made…”, which doesn’t get to Tyrian subs.

Long shot, but do you recall if this message was being processed on versions 0.3.2 and lower?

On my application, I temporarily added a delay before sending the Attached message, but it’s not a long-term solution.

---

Unrelated question: Is there a Matrix bridge for the Discord channel?

[davesmith00000]

Evening @gvolpe 👋

Mixed success. 😄

Discord:

t2bot looks easy enough, but I have no idea what I’m doing with Matrix itself. I’ll try and read up more tomorrow.

WebSockets

So it’s late, and I could be making this up at this point, but here’s roughly what I think happens:

1. User fires a cmd to connect to the web socket.
2. Cmds are lazy, so it’s popped on a queue.
3. When evaluated, the command creates a connection immediately, instantly fires any opening socket messages, and then returns an object containing the connection and the subs the user needs to register - but they have NOT been registered yet.
4. It emits another lazy, queued command saying “connected” which the user listens for.
5. The user grabs the event and saves the socket object in their model somewhere.
6. <At this point we get lucky, because the engine runs cmds then subs, if it was the other way around I think the process would do nothing until a new event went through the system 😬>
7. The user takes the stored details from the model and registers the subs in the list.
8. <At this point, we might have a deadlock waiting for an event to trigger re-evaluation of this subs list… but that’s speculation… and luckily some impatient tester sends a message so the subs list is evaulated.>
9. By this time any initial messages are long gone assuming a responsive server.

If I’m right, the fix is to not create/open the connection until we’re also in a position to register the subs in the same pass. Somehow.

It’s a theory. I’ll see if I can prove it, but probably not until the weekend unfortunately…

[davesmith00000]

Unrelated question: Is there a Matrix bridge for the Discord channel?

Given I only vaguely know what the means the answer is almost certainly, no, but happy to look into it?