fix(uv-provider): clone git+ project paths before uv run --project

[acharyaanusha]

Summary

Two related framework bugs found while building a real training example against a deployed Space (#853).

1. UVProvider/from_env(use_docker=False) never actually clones the git URL

EnvClient.from_env(repo_id, use_docker=False) is documented to "clone the space and run it locally with uv," and builds a project_path of git+https://huggingface.co/spaces/{repo_id} for that purpose. But UVProvider:

1. Ran that string through os.path.abspath(), which mangles it (e.g. collapses https:// to https:/ and prefixes the cwd).
2. Passed the result straight to uv run --project <path>, which only discovers a project in a local directory — it has no support for remote git sources.

So the "clones the space" behavior never happened: reset()/step() would hang until the 60s readiness timeout.

Fix: UVProvider now detects a git+-prefixed project_path, leaves it untouched in __init__ (no abspath mangling), and clones it to a temp directory in start() via git clone --depth 1. The temp dir is removed in stop(). Also closes three follow-up leaks found in review: a temp-dir/process leak if start()/wait_for_ready() fails before the EnvClient exists to clean up, no timeout on the git clone subprocess (a hung remote blocked start() forever), and a leak if the spawned process died on its own and start() was called again.

2. connect() no-ops onto a websocket bound to a dead event loop

EnvClient.connect() has a guard — if self._ws is not None: return self — that ignores which event loop established that websocket. This breaks the officially documented pattern (docs/source/guides/async-sync.md):

client = await SomeClient.from_env(...)   # connects inside this loop
with client.sync() as sync_client:        # drives calls on a NEW, separate
    sync_client.reset()                   # background loop

from_env() ends with await client.connect(), binding _ws to whichever loop ran that await (e.g. an asyncio.run() call, closed by the time from_env() returns). .sync() then drives every later call through SyncEnvClient's own dedicated background-thread loop. The no-op guard means the websocket never gets rebound — every reset()/step() schedules work on a live loop while operating on a connection tied to a dead one, causing a hang or an asyncio "Future attached to a different loop" error. Not specific to any one example — any from_env() + .sync() caller hits this.

Fix: EnvClient now tracks which loop created _ws (self._ws_loop). connect() only treats an existing _ws as reusable if the current running loop matches; otherwise it drops the stale reference and connects fresh.

Known limitation, found while testing this against #853: the fix reconnects correctly, but it can't cleanly close the old connection first — its event loop is already gone, so there's no way to send a proper close frame on it. For environments that allow concurrent sessions this is harmless (just one extra idle connection on the server until it times out). But an environment with SUPPORTS_CONCURRENT_SESSIONS = False (single session, e.g. sophistry_bench_sprint_env) will reject the new (real) connection with a capacity error, because the abandoned old one still occupies the session slot from the server's point of view. #853's training script therefore still avoids from_env() + .sync() for that specific env and connects via UVProvider directly instead — this fix narrows the bug's blast radius (no more hang/crash for the common case) but doesn't make the pattern universally safe for single-session environments. Flagging this explicitly rather than overclaiming; a full fix would need a way to force-close a foreign-loop-bound websocket, which isn't straightforward with the websockets library's public API.

Test plan

• tests/test_core/test_uv_provider.py: TestGitProjectPath (8 cases) covering the clone path, the timeout, and both leak scenarios.
• tests/test_core/test_generic_client.py: TestForeignLoopReconnect (3 cases) covering same-loop no-op, foreign-loop reconnect, and disconnect() clearing loop state.
• pytest tests/test_core/ -q — 198 passed, 11 pre-existing skips.
• ruff format --check / ruff check clean.
• Reproduced both original bugs and verified the fixes end-to-end against a real deployed Space (openenv-community/sophistry_bench_sprint_env) — before the fix, from_env(..., use_docker=False) times out after 60s; after, it clones, starts the server, and a real reset()/step() round-trip succeeds.
• Also reproduced the single-session limitation above end-to-end (got a real CAPACITY_REACHED error), confirming the caveat is accurate rather than theoretical.

🤖 Generated with Claude Code

[acharyaanusha]

@burtenshaw Updated this PR — it now covers a second, related framework bug found in the same training example: EnvClient.connect() ignores which event loop a websocket was created on, breaking from_env() + .sync() generally (not specific to one example). Folded that fix in here too (previously a separate PR, #860, now closed) since both are framework-level fixes found while building #853. Both are tested and verified end-to-end against a real deployed Space.

[burtenshaw]

Because thi reconnects when _ws is None. So client = await Client.from_env(...); client.sync().reset() without entering with client.sync() keeps using the websocket from the foreign loop, because sync_client.py (line 185) calls reset() directly and relies on _ensure_connected(). Move the loop-compatibility check into _ensure_connected() or always call connect() before send/receive; add a test for lazy client.sync().reset().

[acharyaanusha]

Good catch, thanks. You're right -- _ensure_connected() had its own independent guard (if self._ws is None) that bypassed connect()'s loop-aware reconnect logic entirely whenever _ws was already set, which is exactly the foreign-loop case. Fixed in 78a1124: _ensure_connected() now always delegates to connect() instead of pre-checking _ws is None itself. Added test_lazy_send_reconnects_without_explicit_connect_call exercising the exact client.sync().reset()-without-prior-connect() pattern you described.