2 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5	48108a3569	fix: a lane that is OFF was not attributable to itself (4295) ... Operator, 2026-09-23: *"clean up the stale service_seen rows"*. **They were not stale.** They were phantoms, written on purpose, and they will come back on every install that turns a lane off — so the rows are the smaller half of this. A celery worker was attributed to its lane by the queues it was CONSUMING. A lane at cap 0 has its consumers cancelled, so it answers `active_queues()` with an empty list, matches no lane, and is dropped. Three consequences, all on the operator's screen at once: 1. The lanes table reported the lane **not answering** — the signal for a crashed worker, not for one the operator turned off. 2. The roster grew a phantom row named **`Worker ()`** — the empty queue set rendered as a display name — shown "running" beside the real lane's row going stale, because nothing updated it any more. 3. **The container went unhealthy.** `healthcheck._lanes_ok` requires every lane present. ML ships at cap 0, so a fresh install was permanently unhealthy and Swarm restarts an unhealthy task forever. That third one is the severe one, and its docstring asserted the opposite of what the code did — *"a disabled lane still runs its process with its consumers cancelled, so it answers inspect and is healthy"*. It answers. It was not attributed. A comment can be right about the intent and wrong about the program, and this one had been wrong since the consolidated container shipped. `worker_lanes.lane_for_node` attributes by NODE NAME instead: identity travels with the process rather than with what it happens to be doing. `gen_supervisord` already sets `CELERY_NODENAME={lane.name}` per program — the information was there and nothing read it. Falls back to the queue set for a deployment that names no node, and `docker-compose.yml` now sets one per service so the multi-service stack gets it too. The roster keys on the LANE's queue set when the node resolves, which is the same string the row already had while it was consuming — so an existing row keeps updating rather than a second one appearing. Migration 0106 deletes the one key the bug produced, `celery:`. Deliberately NOT a retention sweep: the roster never forgets on purpose, so a quiet row is what it is FOR, and only a row that cannot correspond to anything real is safe to remove. An `agent:agent` row, if one exists, is left alone — nothing here can tell an abandoned agent id from a second agent that is genuinely down, and hiding a dead GPU agent is the one thing the roster must not do. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-23 15:21:21 -04:00
bvandeusenandClaude Opus 5	f23ab9f50e	fix: the roster's inspect budget was exactly the work it waited for (4295) ... From the operator's first consolidated deploy, 2026-09-23. The app is serving — showcase, thumbnails, a Patreon ingest tick, all five lanes in one container — and this repeats in the log: WARNING service roster: celery inspect failed; roster not refreshed File "service_roster.py", line 138, in refresh_celery_roster grouped = await asyncio.wait_for(...) TimeoutError The inspect calls were working. The budget was wrong. `_inspect_celery_sync` makes TWO broadcasts — `active_queues()` and `active()` — and a broadcast with no `destination` cannot know how many replies to expect, so each waits out its full timeout rather than returning on the last reply. The sync call costs ~2 x INSPECT_TIMEOUT_SECONDS. The wrapper allowed `INSPECT_TIMEOUT_SECONDS * 2`. That reads like a safety factor and is precisely the worst case with nothing left over — and this runs on a web process that was serving ninety thumbnails a second at the time, so the thread handing off through `asyncio.to_thread` need not even be scheduled inside the budget. A budget equal to the work fails under any load at all. Now derived: `INSPECT_TIMEOUT_SECONDS * INSPECT_ROUND_TRIPS + slack`, with the round-trip count named beside the calls it counts. Both tests assert the RELATION rather than the numbers, and one reads the source to check the count still matches the calls actually made — a third inspect call added later is exactly how this comes back silently. Consequence while it was broken: the roster stopped advancing and the System tab's rows went stale, with a traceback per attempt. Never an outage — `refresh_celery_roster` catches and returns, `/api/system/health` kept answering 200 throughout, which the same log shows. ## Observed, not fixed here `worker_control.inspect_lanes_sync` makes FOUR of these broadcasts (active_queues, stats, active, reserved) at 2.0s each — roughly 8s — and `lane_view` awaits it with no deadline at all. That is the Settings -> Activity -> Worker lanes card, so that card likely takes ~8s to load, and the composite healthcheck carries the same cost against its 15s timeout. Reported to the operator rather than changed: they are mid-deploy, and the fix is to cut round trips rather than raise a number. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LVjrnpQjRgHdvq95rASoiR	2026-09-23 10:32:09 -04:00