Page Refresh now restarts agent loop if status is STOPPED or ERROR #6829
Conversation
|
Can't we try, on refresh, to reconnect the runtime? |
That is what this PR does - before this PR, the problem was that the agent loop would be running, and therefore would not restart. Now, a disconnected runtime triggers the agent loop to stop, so that a page refresh will restart the agent loop and thereby trigger a reconnect / restart of the runtime. |
There was a problem hiding this comment.
You're right we need a solution for that behavior, thank you for this.
I'm not sure this is quite the way to do it, but I may be wrong. The message callback channel was intended for displaying the error strings in the UI, using it to close the entire session is a bit surprising. What if we reconnect the runtime at refresh, and close the old agent loop if it was disconnected, at that time, at refresh time, does that make sense?
|
On a side note, I wonder what will happen when the user has more useful things to do even without a runtime available right now: right now they can chat with the LLM, and they can try to create a delegate (these actions are not runnable actions, so they don't require a runtime). What if we make a summarization tool, the user could use? (it's not runtime either), or integrate MCP? Just wondering, maybe I'm missing something, would they be possible with this PR? |
I like this approach better. I'll update the PR. |
openhands/server/conversation_manager/standalone_conversation_manager.py
Outdated
Show resolved
Hide resolved
…:All-Hands-AI/OpenHands into fix-disconnected-runtime-stop-agent-loop
This reverts commit bf82f75.
…me-stop-agent-loop
tofarr
changed the title
| if isinstance(event, AgentStateChangedObservation): | ||
| if event.agent_state in ( | ||
| AgentState.STOPPED.value, | ||
| AgentState.ERROR.value, |
There was a problem hiding this comment.
I think it can be STOPPED after FINISHED for "good" reasons, not only for errors, though I could be wrong. Anyway if it stops and restarts in some innocent cases, I'm not sure that's necessarily a bad thing.
Agreed - I had actually only added that in here because I was testing both at the same time in the SAAS staging environment |
End-user friendly description of the problem this fixes or functionality that this introduces
The AgentLoop is now restarted on reconnect if the status is STOPPED or ERROR
Give a summary of what the PR does, explaining any non-trivial design decisions
If the runtime stops (Possibly due to an external error, out of memory, or issue with Kubernetes / Docker), the server would continue without a runtime, spewing errors but not actually handling the error properly. After this change, the AgentLoop will be restarted on reconnect
Example
This silly conversation...
If the docker container is deleted...
On main subsequent prompts fail, telling users to refresh the page...
But refreshing the page does not clear the issue - the Agent remains in the Error state.
After the change, a page refresh will restart the runloop. (Because it has been stopped!) The agent is still aware that something went wrong, as evidenced by the output from a continue prompt:
Link of any specific issues this addresses
To run this PR locally, use the following command: