[Bug]: FastAPI WebSocket with staticfiles
Is there an existing issue for the same bug?
- [x] I have checked the existing issues.
Describe the bug and reproduction steps
after i start openhands,
docker run -it \
--pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.23-nikolaik \
-e LOG_ALL_EVENTS=true \
-e SANDBOX_USER_ID=$(id -u) \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
-p 3000:3000 \
docker.all-hands.dev/all-hands-ai/openhands:0.23
webUI is connection, And I got error log
OpenHands Installation
Docker command in README
OpenHands Version
docker.all-hands.dev/all-hands-ai/openhands:0.23
Operating System
Linux
Logs, Errors, Screenshots, and Additional Context
ERROR: Exception in ASGI application
Traceback (most recent call last):
File "/app/.venv/lib/python3.12/site-packages/uvicorn/protocols/websockets/wsproto_impl.py", line 235, in run_asgi
result = await self.app(self.scope, self.receive, self.send) # type: ignore[func-returns-value]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/.venv/lib/python3.12/site-packages/uvicorn/middleware/proxy_headers.py", line 60, in __call__
return await self.app(scope, receive, send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/.venv/lib/python3.12/site-packages/engineio/async_drivers/asgi.py", line 75, in __call__
await self.other_asgi_app(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/fastapi/applications.py", line 1054, in __call__
await super().__call__(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/applications.py", line 113, in __call__
await self.middleware_stack(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/middleware/errors.py", line 152, in __call__
await self.app(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/middleware/base.py", line 101, in __call__
await self.app(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/middleware/base.py", line 101, in __call__
await self.app(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/middleware/base.py", line 101, in __call__
await self.app(scope, receive, send)
[Previous line repeated 1 more time]
File "/app/.venv/lib/python3.12/site-packages/starlette/middleware/cors.py", line 77, in __call__
await self.app(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/middleware/exceptions.py", line 62, in __call__
await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
raise exc
File "/app/.venv/lib/python3.12/site-packages/starlette/_exception_handler.py", line 42, in wrapped_app
await app(scope, receive, sender)
File "/app/.venv/lib/python3.12/site-packages/starlette/routing.py", line 715, in __call__
await self.middleware_stack(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/routing.py", line 735, in app
await route.handle(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/routing.py", line 460, in handle
await self.app(scope, receive, send)
File "/app/.venv/lib/python3.12/site-packages/starlette/staticfiles.py", line 91, in __call__
assert scope["type"] == "http"
^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
but i can use it anyway
Weird. That's good that you can still use it. What linux dist are you running?
Oh wait I'm getting this too when attaching my local filesystem.
Weird. That's good that you can still use it. What linux dist are you running?
Tencent Linux, seems like ≈Centos6.6
# uname -r
6.6.26-1.0.tl4.x86_64
I did nothing, but seems this problem is gone, then I still want to why, if you know, please tell me
I think this happens when you attach a filesystem to OpenHands. I got it yesterday multiple times.
But I still attach a filesystem now LOL, By environment:
export WORKSPACE_BASE=$(pwd)
docker run xxx \
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE \
-v $WORKSPACE_BASE:/opt/workspace_base \
xxx
haha that's strange. Unsure but let's keep an eye on this.
Hello OH team, just built the docker image from scratch and ran it for the first time using the Quickstart command from the README - also experiencing the same error. To be clear, I didn't attach a filesystem to OH.
docker run -it --rm --pull=always \
-e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.26-nikolaik \
-e LOG_ALL_EVENTS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-v ~/.openhands-state:/.openhands-state \
-p 3000:3000 \
--add-host host.docker.internal:host-gateway \
--name openhands-app \
docker.all-hands.dev/all-hands-ai/openhands:0.26
After running this, I get the same error mentioned by @NICK-DUAN.
ERROR: Exception in ASGI application
Traceback (most recent call last):
File "/app/.venv/lib/python3.12/site-packages/uvicorn/protocols/websockets/wsproto_impl.py", line 235, in run_asgi
...
The localhost:3000 just outputs a 500 Internal Server Error
@mistermjtek When you say you built the docker image from scratch, what do you mean by that?
@mamoodi it just means I had never previously built it before, and it was my first time running the command.
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.
+1
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.
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.
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.
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.
This issue was automatically closed due to 50 days of inactivity. We do this to help keep the issues somewhat manageable and focus on active issues.