Fix closing sessions

[tofarr]

End-user friendly description of the problem this fixes or functionality that this introduces

This PR improves the handling of multiple conversations and session management in OpenHands. It ensures that user workspaces are preserved even after disconnections or server restarts, and implements a smart session management system that automatically handles conversation limits.

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

Improved multi-conversation support with automatic session management and workspace preservation. Users can now maintain multiple conversations across different tabs while ensuring their work is preserved, even after disconnections or server restarts.

---

Summary of Changes

• Added user_id tracking to sessions for better user-specific resource management
• Implemented proper closing of stale sessions to prevent resource leaks
• Added "agent stopped" event emission for better frontend state management
• Enhanced recovery mechanism to preserve workspace/files after disconnection
• Added smart session management for handling multiple conversations

Acceptance Criteria for Multi-conversation Runtime Management

Recovery

• Start a conversation
• Disconnect
• Restart the server
• Verify workspace/files are preserved

Conversation Limits

• Start 4 conversations in different tabs
• First conversation goes to "agent stopped"
• Sending a new message starts it back up, and another conversation goes to "agent stopped"
• Verify workspace is totally recovered

---

Testing Instructions

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:602b370-nikolaik   --name openhands-app-602b370   docker.all-hands.dev/all-hands-ai/openhands:602b370
  -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:b2a0de2-nikolaik \
  --name openhands-app-b2a0de2 \
  docker.all-hands.dev/all-hands-ai/openhands:b2a0de2

[rbren]

why did we lose this?

[rbren]

I guess we just leave _attached_conversations until the whole thing closes? That seems reasonable actually...

[tofarr]

The concept of stored detached conversations was replaced with a general concept of session staleness. A session is considered stale and subject to close if...

• It does not have any connections to it.
  AND...
• It has not had an update within the close_delay (Now 15 seconds by default).

Note: I think there may actually have been a bug here before my changes where the stale check was initialized along with the runloop and was not always being hit.

[enyst]

I assume you mean 15 minutes? 😅 15 seconds seems unbelievably low, just a quick tab away

[tofarr]

Correct. It is 15 minutes. (I actually changed this from 15 seconds to 15 minutes on Monday:

OpenHands/openhands/core/config/sandbox_config.py

Line 63 in ff9058e

close_delay: int = 900

)

[rbren]

Suggested change

	async def get_running_agent_loops_in_cluster(
	async def get_running_agent_loops_remotely(

this seems like maybe a better name?

[tofarr]

Done!

[rbren]

why remove?

[rbren]

I guess we just leave _attached_conversations until the whole thing closes? That seems reasonable actually...

[rbren]

We need to remove this config right?

[tofarr]

AFAIK, there are OSS users that use this value - they have a use case where they want a session to persist for 8 hours while there is no connection to it. (As opposed to the 15 seconds we have by default)

[diwu-sf]

Yep, we have been using a long N hours close_delay to keep our workspaces running around even after every browser closes.

With this new PR, is there a better way to achieve the same effect?

[tofarr]

@diwu-sf - The settings you currently use should be fine - but you may get away with a shorter delay because the new behavior is that a conversation will be stopped if all three of the following are true:

1. It has not been updated in close_delay seconds.
2. There are no connections to it.
3. The agent is not in a running state. (This one is new!)

Now that I think about it, one thing that may affect you is that we have introduced a limit of 3 concurrent conversations per user. (So if you already have 3 running and start another it will kill one of the old ones regardless of the 3 criteria above - this is designed to stop the system crashing due to users trying to start too many concurrent docker containers). If this will affect you, we can introduce a config setting for this too.