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
{{ message }}
Repository navigation
[console] Six UI defects: Teamwork unwireable, runner dot stuck online, frozen status badge, wedged Loop start, slow first paint #190
Found by a read-only audit that cross-checked every console fetch against its actual route handler. All six confirmed against the handlers.
1. Teamwork picker is always empty — supervision and connections cannot be wired from the UI at all. TeamworkSection read /v1/instances/my/instances as a bare array; the route returns {instances}. Array.isArray was therefore always false, both selects held only their placeholder, both Add buttons stayed disabled, and existing links rendered raw UUIDs. Every other caller in the console reads data.instances.
2. The header runner dot says "Runner online" while the runner is off.
It read d.connected ?? !!d.runtime; the route returns {runtime, health, capabilities, relay:{connected, runnerNode}}. There is no top-level connected, so it fell through to !!d.runtime — true whenever a runtime row has ever existed. A missing socket is a 503 from the relay DO rather than a throw, so the route still answers 200, and the 4s poll kept re-confirming "online" while every runner-backed action failed. The node name read snake_case runner_node against a camelCase response, so it was always blank. SettingsTab fixed exactly this; the header was never updated.
3. The Coding header status badge is frozen on "Idle" for the whole session. pollStatuses is the only writer of repoStatuses and is disabled precisely while a session is open. pollTerminal fetches runState in the same payload and threw it away. The badge added to say Working/Idle never changed.
4. Starting the Loop can wedge it "running" with nothing scheduled. startWith set loopOn true, then chained .then() on the first instruction POST with no .catch. If that POST rejects (runner offline, session ended), no step is ever scheduled, the rejection escapes unhandled, and the UI shows the Stop square at iteration 0 forever.
5 & 6. Usage and Terminals show "Loading…" for a full poll interval on every visit. usePolling only fires on the interval — it holds fn in a ref and its effect deps are [ms, enabled]. Neither page had a mount fetch, so the first request went out 30s / 5s after mount. On Usage this also meant the range selector kept rendering the previous range's numbers, with no spinner, until the next tick.
Activity
perf(coder): the polls slow down when nothing is happening (#83)