Jobs page: highlight ACTIVE users, not online users #76
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The jobs page appears to still highlight online users instead of active users (the
lastSeen/active distinction from #31 / #3). Verify against the live jobs API and fix so the highlight reflects active-in-window, not currently-online.Files:
frontend/src/pages/Jobs.tsx,frontend/src/lib/jobsApi.ts.🔒 Reserved by
ward agent --driver claude— containerengineer-claude-eco-app-76on hostKAI-DESKTOP-TOWERis carrying this issue (reserved 2026-07-06T05:13:34Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (2h0m0s TTL);--forceoverrides.Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).
run seed context — what this run is carrying (ward#609)
coilyco-gaming/eco-app#76· branchissue-76· driverclaude· workflowdirect-mainengineer-claude-eco-app-76· wardv0.413.0· dispatched2026-07-06T05:13:34ZIssue body as seeded:
Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.413.0).
— Claude (she/her), via
ward agent🔓 Reservation released by
ward container reap— containereco-app(--driver claude) exited at the auth pre-launch gate without launching the agent (ward#222/#264/#609), so the hold it took is retracted. A plainward agentretry no longer needs--force.Gate: auth smoke test (claude credentials)
Recovery: Refresh the host claude login (re-run
claudeon the host to re-auth), then re-dispatch.error from the gate
— Claude (she/her), via
ward agent🔒 Reserved by
ward agent --driver claude— containerengineer-claude-eco-app-76on hostKAI-DESKTOP-TOWERis carrying this issue (reserved 2026-07-06T05:36:41Z). Concurrentward agentruns are blocked until it finishes or the reservation goes stale (2h0m0s TTL);--forceoverrides.Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).
run seed context — what this run is carrying (ward#609)
coilyco-gaming/eco-app#76· branchissue-76· driverclaude· workflowdirect-mainengineer-claude-eco-app-76· wardv0.413.0· dispatched2026-07-06T05:36:41ZIssue body as seeded:
Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.413.0).
— Claude (she/her), via
ward agentWARD-OUTCOME: done - jobs
lastSeennow anchors to persistedLastOnlineTime, not session-scopedLogoutTime, so offline-but-recently-active players stop collapsing to inactive.This one wore a disguise. The issue points at
Jobs.tsxandjobsApi.ts, but those are innocent - they faithfully render whateveractivethe API hands them, and the Python tracker windowslastSeencorrectly too. The whole pipeline looked right, which is exactly what made it slippery.Verifying against the live API is what cracked it: the jobs
activeset was precisely the 4 online players, while the server's own count was ~32 active. So the leak had to be upstream, in the mod. The tell that the new mod is actually deployed (and not the oldactive:boolshim) was the citizens id->name join working live on the crafting page - that endpoint shipped after thelastSeenchange, so its presence implieslastSeenis present too. From there it was reading the real EcoUserAPI out of the reference assemblies:LogoutTimeonly gets set on a same-session logout, so after any restart it's 0 for everyone offline, and they all fell out of the active window.LastOnlineTimeis the persisted sibling that survives restarts.Confidence: high on the diagnosis and that the code is correct; medium that it fully matches Eco's runtime, since I can't boot a real Eco server in here - it's compile-verified against the reference assemblies and reasoned from the API, not observed end-to-end. The honest caveat: this won't change the live page until the mod DLL redeploys at the next server restart (out of band, same as every mod change here). Worth a glance after that restart to confirm the active count jumps from ~online to ~active. A possible follow-up: there's no C# test harness for the mod, so this class of "which time field" bug can only be caught by eye today - a small mod-level unit/contract test would be a good guard.