OpenHands started fixing the issue! You can monitor the progress here.

Better behavior would be that the agent gets a message that the command timed out but does not stop (this was the behavior in previous versions of Open Hands).

I'll add here for the record: I am unable to reproduce in some normal way this behavior on the local installation (with local docker), it works just fine. I can see it only on the hosted version.

We use many timeouts in the code, and in this case, I've looked at 3 of them:

• the runtime timeout here doesn't get hit on local install, the 5 extra seconds help. I suspect this is the one that gets things messy on the hosted version.
• the bash command timeout around here gets hit, the agent gets the information that the command timed out, and continues normally
• same for the ipython timeout here.

All these have by default the value of sandbox.timeout setting.

I have a similar issue: https://www.all-hands.dev/share?share_id=fcba85aaadd94a7557d6b6d0283ef50fd27c33ec0293d1df4e4f41f84bf86588
LLM: GPT-4o

It would still be great to get this fixed.

The problem here is that the underlying runtime dies (e.g. due to running out of memory) which leaves the HTTP client in the lurch. The HTTP request times out, and we get this error.

It's not an easy fix unfortunately. We could probably add an API to check how many times the runtime has rebooted, and send the user a message like "Runtime rebooted, potentially due to memory usage. Please try again."

OK, sounds good. I confirmed that if I just run a command that times out (sleep 120) I get the expected message.

Separately, this is happening when I run OpenHands unit tests according to our standard unit testing github workflow. A combination of:

1. A better error message (this issue) and
2. Configurable runtime size Add runtime size configuration feature #5805

Should make this significantly better.

OpenHands started fixing the issue! You can monitor the progress here.

An attempt was made to automatically fix this issue, but it was unsuccessful. A branch named 'openhands-fix-issue-5601' has been created with the attempted changes. You can view the branch here. Manual intervention may be required.

Additional details about the failure:
While some progress has been made in understanding the root cause, the issue hasn't been fully resolved yet. From the thread discussion, it became clear that:

1. The original issue is more complex than just a timeout problem - it's related to the underlying runtime dying (e.g., due to memory issues) which causes the HTTP client to timeout.

2. The simple timeout case (like running sleep 120) works as expected, but the more complex cases involving runtime failures still need to be addressed.

3. A proposed solution was mentioned to add an API to check runtime reboot counts and provide better error messages like "Runtime rebooted, potentially due to memory usage. Please try again."

4. The issue is being addressed alongside another PR (Add runtime size configuration feature #5805) for configurable runtime size.

The AI agent's last message seems to be describing an ideal solution but doesn't reflect the actual current state of the fix. The thread indicates this is still an ongoing issue that requires additional work, particularly around handling runtime failures and providing better error messages to users.