OpenHands icon indicating copy to clipboard operation
OpenHands copied to clipboard

[Bug]: [Resolver] crashes on `main`

Open enyst opened this issue 11 months ago • 11 comments

Is there an existing issue for the same bug?

  • [X] I have checked the existing issues.

Describe the bug and reproduction steps

It seems the resolver is broken on main: I ran with the label fix-me-experimental and got

ERROR:root:<class 'AttributeError'>: 'NoneType' object has no attribute 'logs' Exception ignored in: <function LogStreamer.del at 0x7ff5a8fa8220> Traceback (most recent call last): File "/opt/hostedtoolcache/Python/3.12.8/x64/lib/python3.12/site-packages/openhands/runtime/utils/log_streamer.py", line 41, in del AttributeError: 'LogStreamer' object has no attribute 'stdout_thread

Log: https://github.com/All-Hands-AI/OpenHands/actions/runs/12614710302/job/35153871943?pr=6036#step:10:49

It ran on a PR: https://github.com/All-Hands-AI/OpenHands/pull/6036#issuecomment-2571442794

OpenHands Installation

Other

OpenHands Version

main 56d7dccec96d74f5f97abdcb67b93e428caa5a3e

Operating System

None

Logs, Errors, Screenshots, and Additional Context

No response

enyst avatar Jan 04 '25 23:01 enyst

Considering how fast things are moving and the amount of change, would it make sense to change this line: https://github.com/All-Hands-AI/OpenHands/blob/150463e629e1f9f73f5c010a0b24b0f0ff44b0da/openhands/resolver/examples/openhands-resolver.yml#L22

to a specific version/tag? I feel like pointing to main may make this a little unstable.

mamoodi avatar Jan 05 '25 18:01 mamoodi

Well, the resolver has 2 modes basically, from this point of view:

  • it runs on the latest version <= when it's triggered by the label fix-me or we insert the tag @openhands-agent in a comment
  • it runs on main <= when it's triggered by the label fix-me-experimental or we use the tag @openhands-agent-exp in a comment.

So we can choose the stable version, we just have the additional ability to run on main. Livin' on the edge! 😅

Other repos are also able to run on a target branch / main, which uses our main as you pointed out.

(On a side note, that's why we're not sure how to classify these bugs. I do think they're bugs anyway, and they will be in the stable version if we let them (except for the rare case when versioning itself was the problem).

enyst avatar Jan 05 '25 19:01 enyst

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

openhands-agent avatar Jan 05 '25 19:01 openhands-agent

Oops, haha it heard me 😂

enyst avatar Jan 05 '25 19:01 enyst

What's the difference between the "latest version" and "main"? Does latest version mean latest stable version?

mamoodi avatar Jan 05 '25 19:01 mamoodi

Yes! It's 0.18 now

enyst avatar Jan 05 '25 19:01 enyst

Oh that's good to know. So when someone copies this : https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/resolver/examples/openhands-resolver.yml

To their repo and they tag "fix-me" or use its name. Does it also use the latest stable version? Or does it use main?

mamoodi avatar Jan 05 '25 19:01 mamoodi

Let's see!

  • the labeled issue: https://github.com/enyst/litellm/issues/4

Looks like it's 0.18.0, if the label is fix-me:

####openhands-ai==0.18.0

Workflow: https://github.com/enyst/litellm/actions/runs/12622492557/job/35170464204#step:4:67

But I'm getting confused. I think it got the workflow file from main, then it executes on 0.18.0... 🤔

enyst avatar Jan 05 '25 19:01 enyst

Hi @enyst,

I encountered a similar issue and wanted to share my findings. After reviewing the label issue you mentioned, I discovered that the root cause seems to stem from an incorrect installation of OpenHands. This appears to be related to the workflow file, specifically codes around the cat Requirements.txt command. Instead of appending dependencies correctly to the last line, it adds them immediately after the last character in the file.

This behavior causes pip to fail in recognizing the corresponding package, leading to installation issues. For reference, you can check my issue here: https://github.com/All-Hands-AI/OpenHands/issues/5988. In my case, the Requirements.txt file from my repository was used, and the version characters for openhands_ai were appended incorrectly at the end of the last line, causing the installation to fail.

I hope this helps in identifying and resolving the problem!

DylanLIiii avatar Jan 05 '25 20:01 DylanLIiii

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

openhands-agent avatar Jan 15 '25 06:01 openhands-agent

A potential fix has been generated and a draft PR #6284 has been created. Please review the changes.

openhands-agent avatar Jan 15 '25 06:01 openhands-agent

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

github-actions[bot] avatar Feb 16 '25 02:02 github-actions[bot]

I encountered a similar issue and wanted to share my findings. After reviewing the label issue you mentioned, I discovered that the root cause seems to stem from an incorrect installation of OpenHands. This appears to be related to the workflow file, specifically codes around the cat Requirements.txt command. Instead of appending dependencies correctly to the last line, it adds them immediately after the last character in the file.

This behavior causes pip to fail in recognizing the corresponding package, leading to installation issues. For reference, you can check my issue here: #5988. In my case, the Requirements.txt file from my repository was used, and the version characters for openhands_ai were appended incorrectly at the end of the last line, causing the installation to fail.

I hope this helps in identifying and resolving the problem!

Thank you! This is in main.

enyst avatar Feb 16 '25 04:02 enyst