(enh) send status messages to UI during startup

[tobitege]

Short description of the problem this fixes or functionality that this introduces. This may be used for the CHANGELOG

Make it possible to send status messages from backend to UI.

---

Give a summary of what the PR does, explaining any non-trivial design decisions

• Frontend: add status message display below existing agent status message area; additions to FE for a status message slice and handling
• The sent messages are actual translations keys as contained in translation.json, e.g. STATUS$WAITING_FOR_CLIENT
• Added loads of missing translations with the help of Sonnet
• In the session.py file, method queue_status_message is the main sender
• runtimes: added parameter to pass in a status_message_callback that is aimed to be called from inside the runtime if it wants to send status messages to the UI
• in EventStreamRuntime added only a couple status messages
• folder server/session: in session.py added a task to manage a status message queue which gets sent to the UI
• renamed server/session/agent.py to agent_session.py - too many files are just named agent, imho

---

Link of any specific issues this addresses

There are many open issues which stem from the fact, that during startup, there is no extra feedback. Especially if no docker images are present a lot of time-consuming operations have to be taken care of at initial startup. This can take several minutes, only on repeat sesssions this time would be shorter (or a fixed image were specified).

[tobitege]

@enyst - I now reverted the changes related to latest_session_id in manager.py as per our convo.

[rbren]

@tobitege this looks cool!

My hope is that (per https://github.com/All-Hands-AI/OpenHands/pull/3794) we can avoid having an extra CLIENT_READY, and just make sure that AGENT_READY means the runtime is ready too. Otherwise you could get a race--we can't guarantee which one is ready first

[tobitege]

@tobitege this looks cool!

My hope is that (per #3794) we can avoid having an extra CLIENT_READY, and just make sure that AGENT_READY means the runtime is ready too. Otherwise you could get a race--we can't guarantee which one is ready first

Maybe it's semantics here, but the agent shouldn't "appear" ready before the client. We can disguise the state then accordingly, I guess.

This PR has still the issue about the frontend code, which I need assistance with and the "flow" of states.

[rbren]

Maybe it's semantics here, but the agent shouldn't "appear" ready before the client. We can disguise the state then accordingly, I guess.

100% agree here. This is basically what my PR does--it forces the runtime to be ready before the agent is allowed to report that it's ready

[enyst]

This is awesome work, thank you for doing this! It responds to a need that IMHO will lead to a nice improvement in user experience.

[tobitege]

Maybe it's semantics here, but the agent shouldn't "appear" ready before the client. We can disguise the state then accordingly, I guess.

100% agree here. This is basically what my PR does--it forces the runtime to be ready before the agent is allowed to report that it's ready

I had tried your change yesterday or earlier today (the extra call to _wait_until_alive), but also ran during tests in a situation where that could then hang up the container, but might have been coincidental.

[tobitege]

Finally fixed the "blank page" error so that at least an actual status message can be displayed. Right now, the first message that would appear is in EventStreamRuntime, at the bottom of _init_container: self.send_status_message('Status: Container started.')

Any earlier attempts do not make it to the UI, which is now the big open issue.

EDIT: comment outdated

[tobitege]

Maybe it's semantics here, but the agent shouldn't "appear" ready before the client. We can disguise the state then accordingly, I guess.

100% agree here. This is basically what my PR does--it forces the runtime to be ready before the agent is allowed to report that it's ready

I've put in that self._wait_until_alive() call (EventStreamRuntime.__init__) and removed the previous CLIENT_READY status.

[tobitege]

Seems to work now, but need advice on the UI changes if they need further refinements.

[amanape]

Maybe you can remove the "(may take up to 10 seconds)" text entirely and leave in the "Initializing agent" since the status message already mentions the estimated time (Preparing container, this might several minutes...)

[tobitege]

Maybe you can remove the "(may take up to 10 seconds)" text entirely and leave in the "Initializing agent" since the status message already mentions the estimated time (Preparing container, this might several minutes...)

Ooops just now realize the typo in the message ("take" is missing)

[rbren]

This is looking cool!

I would very much suggest combining the messages in the UI, instead of displaying both of them. I'd replace the generic "initializing agent" with the more specific status messages you're sending back.

[tobitege]

How the heck is there a lint error after going through pre-commit checks? 😔

[tobitege]

@rbren applied tweaks, translations, code cleanup.

[tobitege]

This editing by suggestions is a bit weird lol

[rbren]

@tobitege I made a small UI change to combine the status messages (the two-line treatment won't work with the new UI Stephan is working on)

If that looks good to you, :shipit: !

Thanks for doing this, it's a huge UX improvement

[tobitege]

@tobitege I made a small UI change to combine the status messages (the two-line treatment won't work with the new UI Stephan is working on)

If that looks good to you, :shipit: !

Thanks for doing this, it's a huge UX improvement

Yes, this change should work just fine, it's "either/or" anyways.

Happy that this will help out! 🎉

[tobitege]

~~it's not quite working, something broke in the FE, working on it~~ Fixed.