Light up the citizen id→name association: deploy CitizensApiController + verify user.Id matches the exporter Citizen id [restart-gated] #65

Open
opened 2026-07-05 05:07:39 +00:00 by coilysiren · 0 comments
Owner

Problem

The citizen id -> name join built in #5 (closed) is not actually lit up in production. The machinery exists - realignment-tolerant row parsing plus the join via a new jobs-mod endpoint /api/v1/citizens (CitizensApiController.cs, with a Citizen #<id> fallback) - but two gaps keep it from resolving real names on the live server, and neither was tracked:

  1. Unverified. The #5 engineer flagged (close-out retro) that the C# side was code-review-only (no dotnet / Eco SDK / live server in-container). The load-bearing assumption - that user.Id is the same numeric the action exporter emits for Citizen/Buyer/Seller/ShopOwner - was never confirmed against live data. If it diverges, the join returns empty and everything degrades to Citizen #<id> labels. Their recommended "verify against a live cycle" follow-up was never filed.
  2. Undeployed. /api/v1/citizens ships inside the EcoJobsTracker DLL, but #31 reports the DLL on kai-server is still a stale pre-#3 build that predates CitizensApiController entirely. So the endpoint is not serving on the live server - the join has nothing to call.

Why this is high-leverage

Every per-citizen view depends on this resolving: #12 by-citizen distributions, #17 crafter leaderboards, #61 civics (who voted/won), #64 progression, plus #6 trade names and #50 store owners. Until this is lit up, all of them silently render Citizen #<id> instead of names - graceful (no crash) but the difference between a real dashboard and a wall of numbers.

Tasks

  1. Deploy the jobs-mod DLL carrying CitizensApiController (and the #31 lastSeen field) to kai-server so /api/v1/citizens serves. Coordinate with #31 - one mod push should carry both.
  2. Verify against a live cycle that /api/v1/citizens user.Id matches the numeric the action exporter emits for Citizen/Buyer/Seller/ShopOwner. Probe per the dataset how-to. If it diverges, CitizenDto needs the correct/extra identifier field.
  3. Confirm end to end that a per-citizen surface (crafting "Top crafters", the trades ledger, or the economy distributions) renders real names, not Citizen #<id>.

Restart constraint

This is restart-gated - it needs the mod deployed (a DLL push + server restart), so it lands in the next-restart-window bucket alongside #31 and #55 (the stores-mod activation), not on the no-restart track. The verify step (task 2) cannot run until the endpoint serves.

Acceptance

  • /api/v1/citizens serves live on kai-server (one push carrying #5's CitizensApiController + #31's lastSeen).
  • The user.Id == exporter-Citizen-id match is verified on a live cycle and documented; if divergent, the DTO carries the correct identifier.
  • A live per-citizen surface shows real names, not Citizen #<id>.

Refs

Built by #5 (closed). Mod rollout sibling #31. Survey #7. Consumers: #6, #12, #17, #50, #61, #64. Origin: eco-app director session, 2026-07-05, flagged by Kai.

## Problem The citizen **id -> name** join built in [#5](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/5) (closed) is not actually lit up in production. The machinery exists - realignment-tolerant row parsing plus the join via a new jobs-mod endpoint `/api/v1/citizens` (`CitizensApiController.cs`, with a `Citizen #<id>` fallback) - but two gaps keep it from resolving real names on the live server, and neither was tracked: 1. **Unverified.** The [#5](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/5) engineer flagged (close-out retro) that the C# side was code-review-only (no dotnet / Eco SDK / live server in-container). The load-bearing assumption - that **`user.Id` is the same numeric the action exporter emits for `Citizen`/`Buyer`/`Seller`/`ShopOwner`** - was never confirmed against live data. If it diverges, the join returns empty and everything degrades to `Citizen #<id>` labels. Their recommended "verify against a live cycle" follow-up was never filed. 2. **Undeployed.** `/api/v1/citizens` ships inside the EcoJobsTracker DLL, but [#31](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/31) reports the DLL on kai-server is still a stale pre-#3 build that predates `CitizensApiController` entirely. So the endpoint is not serving on the live server - the join has nothing to call. ## Why this is high-leverage Every per-citizen view depends on this resolving: [#12](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/12) by-citizen distributions, [#17](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/17) crafter leaderboards, [#61](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/61) civics (who voted/won), [#64](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/64) progression, plus [#6](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/6) trade names and [#50](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/50) store owners. Until this is lit up, all of them silently render `Citizen #<id>` instead of names - graceful (no crash) but the difference between a real dashboard and a wall of numbers. ## Tasks 1. **Deploy** the jobs-mod DLL carrying `CitizensApiController` (and the [#31](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/31) `lastSeen` field) to kai-server so `/api/v1/citizens` serves. **Coordinate with [#31](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/31) - one mod push should carry both.** 2. **Verify** against a live cycle that `/api/v1/citizens` `user.Id` matches the numeric the action exporter emits for `Citizen`/`Buyer`/`Seller`/`ShopOwner`. Probe per the [dataset how-to](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/src/branch/main/docs/datasets/README.md). If it diverges, `CitizenDto` needs the correct/extra identifier field. 3. Confirm end to end that a per-citizen surface (crafting "Top crafters", the trades ledger, or the economy distributions) renders **real names**, not `Citizen #<id>`. ## Restart constraint This is **restart-gated** - it needs the mod deployed (a DLL push + server restart), so it lands in the next-restart-window bucket alongside [#31](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/31) and [#55](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/55) (the stores-mod activation), not on the no-restart track. The verify step (task 2) cannot run until the endpoint serves. ## Acceptance * `/api/v1/citizens` serves live on kai-server (one push carrying #5's `CitizensApiController` + #31's `lastSeen`). * The `user.Id` == exporter-`Citizen`-id match is verified on a live cycle and documented; if divergent, the DTO carries the correct identifier. * A live per-citizen surface shows real names, not `Citizen #<id>`. ## Refs Built by [#5](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/5) (closed). Mod rollout sibling [#31](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/31). Survey [#7](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/7). Consumers: [#6](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/6), [#12](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/12), [#17](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/17), [#50](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/50), [#61](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/61), [#64](https://forgejo.coilysiren.me/coilyco-gaming/eco-app/issues/64). Origin: eco-app director session, 2026-07-05, flagged by Kai.
coilyco-ops added
P3
and removed
P2
labels 2026-07-10 09:00:49 +00:00
Sign in to join this conversation.
No description provided.