Skip to content

[console] Six UI defects: Teamwork unwireable, runner dot stuck online, frozen status badge, wedged Loop start, slow first paint #190

Closed

Description

@serge-ivo

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.

All six fixed in one pass.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions