[Bug]: [Resolver] crashes on `main`
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
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.
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-meor we insert the tag@openhands-agentin a comment - it runs on
main<= when it's triggered by the labelfix-me-experimentalor we use the tag@openhands-agent-expin 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).
Oops, haha it heard me 😂
What's the difference between the "latest version" and "main"? Does latest version mean latest stable version?
Yes! It's 0.18 now
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?
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... 🤔
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!
A potential fix has been generated and a draft PR #6284 has been created. Please review the changes.
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.
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.