You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
but websockets>=16.0 is required for desktop_streaming_manager + slm_client (Issue #3098). The two are mutually exclusive in one env, so 1.3.2 is the current ceiling (keeps the PVE-2026-88512 SQL-injection fix, which is in ≥1.3.1).
Note: main currently has the unbuildable combo langchain>=1.3.10 + websockets>=16.0 (latent; never smoke-built on main). The reconcile PR #10380 corrects it to 1.3.2.
Goal (option B)
Reach the highest langchain (≥1.3.10) while keeping WebSocket features working. Investigate, in order of preference:
Is websockets>=16.0 truly required, or will desktop_streaming_manager / slm_client work on websockets 15.x? If 15.x is fine, relax the pin (e.g. >=15.0) → langgraph-sdk 0.4.2 + langchain 1.3.10 resolve. (Verify the actual websockets API usage in those modules + run the WebSocket smoke paths.)
Upstream: check for a langgraph-sdk release (>0.4.2) that supports websockets>=16; if available, bump langgraph/langchain together.
If neither: document 1.3.2 as the intentional ceiling with this rationale.
Acceptance
langchain at the highest version compatible with a working WebSocket stack (target ≥1.3.10), backend smoke-test green, desktop streaming + SLM WebSocket verified.
→ strict (Docker) pip resolution → ResolutionImpossible. So langgraph is pinned to ≤1.2.4 (which pulls the constraint-free langgraph-sdk 0.3.15), holding langchain at 1.3.2 and langgraph at 1.2.2 in the image.
The cap is FALSE (verified on the running backend venv)
The deployed venv runs langgraph 1.2.5 + langgraph-sdk 0.4.2 + websockets 16.0 and works — langgraph-sdk's websockets<16 cap is for its cloud/remote client (get_client over WS), which AutoBot does not use (we use langgraph locally via StateGraph). websockets 16 still ships WebSocketServerProtocol, so desktop_streaming_manager is fine.
No upstream fix available
Every langgraph-sdk 0.4.x (incl. latest 0.4.2) keeps websockets<16; no release relaxes it. So the only path is a dependency override.
Recommended fix (deferred — touches the Docker build)
Lowest-risk: targeted post-install override in docker/backend/Dockerfile after the main pip install:
# langgraph-sdk's websockets<16 cap is for its unused cloud client; AutoBot runs langgraph locally.RUN pip install --no-deps --upgrade langchain==1.3.10 langchain-core==1.4.8 langgraph==1.2.6 langgraph-sdk==0.4.2
(Alternative: switch the build to uv with override-dependencies = ["websockets>=16"] — cleaner but a build-tool swap; medium risk, can't be validated locally without Docker.)
Both must be validated via CI Docker build. Held out of #10427 deliberately to keep that PR CI-safe. Same pattern also affects opencv 4.13 (blocked by graspologic 3.4.4's stale numpy<2.0, which the venv also disproves at numpy 2.4.6) — an override-dependencies = ["numpy>=2.0"] would unblock it.
Activity
chore(deps): raise backend dep floors to latest, ecosystem-capped pac…
chore(deps): raise backend dep floors to latest, ecosystem-capped pac…
mrveiss commentedon Jun 21, 2026
Root cause confirmed + concrete upgrade path
Investigated while bringing backend deps to latest (#10427). The blocker chain:
langgraph >= 1.2.5requireslanggraph-sdk >= 0.4.2langgraph-sdk >= 0.4.0declareswebsockets <16,>=14websockets >= 16.0(websockets package missing from backend requirements.txt #3098 —desktop_streaming_manager,slm_client)→ strict (Docker) pip resolution →
ResolutionImpossible. Solanggraphis pinned to ≤1.2.4 (which pulls the constraint-freelanggraph-sdk 0.3.15), holdinglangchainat 1.3.2 andlanggraphat 1.2.2 in the image.The cap is FALSE (verified on the running backend venv)
The deployed venv runs langgraph 1.2.5 + langgraph-sdk 0.4.2 + websockets 16.0 and works —
langgraph-sdk'swebsockets<16cap is for its cloud/remote client (get_clientover WS), which AutoBot does not use (we use langgraph locally via StateGraph). websockets 16 still shipsWebSocketServerProtocol, sodesktop_streaming_manageris fine.No upstream fix available
Every
langgraph-sdk0.4.x (incl. latest 0.4.2) keepswebsockets<16; no release relaxes it. So the only path is a dependency override.Recommended fix (deferred — touches the Docker build)
Lowest-risk: targeted post-install override in
docker/backend/Dockerfileafter the main pip install:(Alternative: switch the build to
uvwithoverride-dependencies = ["websockets>=16"]— cleaner but a build-tool swap; medium risk, can't be validated locally without Docker.)Both must be validated via CI Docker build. Held out of #10427 deliberately to keep that PR CI-safe. Same pattern also affects opencv 4.13 (blocked by graspologic 3.4.4's stale
numpy<2.0, which the venv also disproves at numpy 2.4.6) — anoverride-dependencies = ["numpy>=2.0"]would unblock it.deps(backend): relax websockets to >=15,<16 to unblock langchain >=1.…
github-actions commentedon Jun 22, 2026
PR #10462 (merged to
Dev_new_gui) references this issue with a close keyword.If this issue is fully resolved, close it manually. If work remains, no action is needed.
mrveiss commentedon Jun 22, 2026
Merged to
Dev_new_gui(19e4ba479, PR #10462).websocketsrelaxed to>=15.0,<16(both consumers use only 15.x-compatible API; CI already pinned 15.0.1), unblockinglangchain>=1.3.10(+ aligned langchain-core 1.4.7 / community 0.4.2 / langgraph 1.2.5). The<16bound satisfies langgraph-sdk 0.4.2. Backend smoke-test + startup-import-smoke green. Batch #10440.