[Bug]: FileReadObservation.init() got an unexpected keyword argument 'impl_source'

[avi12]

Is there an existing issue for the same bug?

• I have checked the existing issues.

Describe the bug and reproduction steps

https://www.all-hands.dev/share?share_id=89cc5c6565e8372271be4bb803ec6eff0cee8201800be7514a63500edda88490

OpenHands Installation

Docker command in README

OpenHands Version

0.16.1

Operating System

WSL on Windows

Logs, Errors, Screenshots, and Additional Context

No response

[malhotra5]

+1 on this (Workflow log)

[avi12]

It seems like this particular issue was solved with the bot's update

[malhotra5]

Reopening this issue, still facing the issue on main

Sample workflow log

[enyst]

To note, this looks like a version conflict:

• this was merged after 0.16.1 release Use more specific action types for openhands-aci commands #5508
  • it does indeed introduce two new attributes, which don't exist in the 0.16.1 version of the event
• the workflow uses the 0.16.1 version

[malhotra5]

Ah gotcha, how about this workflow log? It's using main but faced the same error

[enyst]

It looks like this is not main, it's 0.16.1... 🤔

[enyst]

I mean line 139 there

[malhotra5]

Ah I see the confusion - the previous step in the workflow checks for the latest version

However for the step that installs the package, I forced it to install from main

When I use the released version 0.16.1, this issue doesn't occur (another workflow log
)

It seems like this is an issue only on main

EDIT: we can confirm this by running fix-me vs fix-me-experimental on an issue; I believe fix-me-experimental will fail

[enyst]

Hmm, how about the sandbox? This code above is running in the sandbox 🤔

[malhotra5]

I believe the resolver runs on eventstream instead of sandbox runtime; am I interpreting this correctly?

EDIT: yeah its running on a sandbox

[enyst]

The "eventstream runtime" is a docker sandbox, which communicates using an API sending/receiving events from the sandbox. It's not local, it's in docker.

EDIT: we can confirm this by running fix-me vs fix-me-experimental on an issue; I believe fix-me-experimental will fail

I ran fix-me-experimental here last night, it worked. The difference might be that your test repo is an external repo, while the successful workflow worked on this repo?

[openhands-agent]

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

[malhotra5]

Possibly! Did a quick test, was able to reproduce the error again on this repo; there may be a PR that caused a regression in the last day or so

[enyst]

Oh, it failed with the same error. 🫣

Line 36: https://github.com/All-Hands-AI/OpenHands/actions/runs/12455745077/job/34768492590#step:10:37

[ryanhoangt]

I think the issue is due to the resolver using a specified runtime image, which skipped the runtime image build process:

OpenHands/openhands/resolver/resolve_issue.py

Lines 593 to 596 in 4a8bf3d

	if runtime_container_image is None:
	runtime_container_image = (
	f'ghcr.io/all-hands-ai/runtime:{openhands.__version__}-nikolaik'
	)

One way to address might be to not specify this runtime image at all, similar to the dev workflow, which can add some build time overhead to the resolver, but can keep it up to date with all the changes in main. What do you guys think?

[glgh]

I'm running into the same issue running openhands locally using the development flow. My repo was synced to ee5f49a