Files
hermes-agent/hermes_cli
ethernet f6f9f89a77 ci(windows-e2e): drop RUST_LOG from the update leg - it manufactured the deadlock it was diagnosing
Run 31457301901 proved both halves of the stderr fix and then hung
anyway, in uv pip install -e .[all] (process table caught it live):

- The SQLite-repair uv sync that deadlocked run 2 now streams its
  whole package list and completes in ~80s WITH debug tracing on -
  managed_uv.py is imported lazily after the git reset, so even this
  old base ran the fixed copy.
- The .[all] install runs _run_install_with_heartbeat from main.py,
  which was imported when hermes update STARTED - the v0.20.1 copy,
  which pipes uv's stderr undrained. RUST_LOG=uv=debug guaranteed
  >64KB of stderr, so the driver's own diagnostic manufactured the
  deadlock. Comments in both fixed call sites now state the real
  import-time reach of each arm.

This also explains run 1 failing WITHOUT tracing: the pipe budget is
cumulative across every child of the update sharing it. The old-code
sync burned ~30KB of it on the package list; the .[all] leg finished
the job. With the sync leg now on stdout, the old .[all] leg's
natural output should fit - which is the real-world story too: old
bases hang or survive on stderr luck, new bases are safe by
construction.
2026-08-11 01:10:57 -04:00
..
2026-08-03 09:57:23 -07:00
…
2026-08-10 12:43:46 -07:00
…
…