Feat: Multi tab support!

[tofarr]

Multiple tabs can now connect to the same session

• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

---

This is not a big functional change right now, but paves the way for future changes where we could potentially have a share session url / multiple users connect to the same session.

• The server now echos Message Actions (So that other connected clients can process them)
• Message Actions now have a secondary id (a UUID). This is required because we often display a prompt on the client before even sending it to the server - so we need a way of telling events apart when multiple clients may be producing prompts.

---

To run this PR locally, use the following command:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:8a5357f-nikolaik   --name openhands-app-8a5357f   docker.all-hands.dev/all-hands-ai/openhands:8a5357f

[enyst]

Can you please tell, why was this necessary?

[tofarr]

If there are multiple tabs / users attached to a session, then we need to make sure that each of the tabs gets input from one user as output - otherwise they only see responses rather than the prompts that generated them - so we now echo all events where the source is USER rather than just CmdOutputObservation instances.

[enyst]

We may need to double check that this works as expected in all cases, for example, the lines below:

• exclude ipython obs
• send error obs as AGENT

I know I meant most obs to be ENV source rather than USER, so if they're ENV and nothing unwanted is USER, these should work fine (tm), but it's worth a quick check.

[enyst]

I mean, you're saying that this change should only refer to actual "user messages", that is, from a person. The change does all events with source USER though, which may be more than that.

[rbren]

Ugh this logic has gotten pretty messy. We're doing a lot of monkeypatch-y things with the events we send down.

IMO the logic should just be self.send(event_to_dict(event)) in all cases, except maybe for a few little exceptions. (e.g. we had an exception here for user messages before, because those were being handled on the FE)

To Engel's point we should probably make sure that commands sent from the FE don't appear double

[enyst]

Or that the error observation is on "agent" side of the chatbox, not the "user" side. 😅

[rbren]

@tofarr just make sure that user interactions w/ the terminal behave as expected, and we can merge this. Would love to simplify this logic a bit in the future

[rbren]

Instead of doing this, can we just show the message when it comes back to us on the websocket?

[tofarr]

I have updated the PR with this change - we now have a pending flag (On the client only), and when a message from the server is received, any pending message on the client is removed.

[diwu-sf]

O Nice, this is the exact kind of experience we needed. In fact, we expect to have multiple browser from different computers connected to the same sock-io session underneath.