fix(db): val terug op de presence-instance-id i.p.v. een unknown-label #116

Merged

janpeter merged 1 commit from fix/db-label-instance-fallback into main 2026-08-16 20:18:48 +02:00

Conversation 0 Commits 1 Files changed 2 +42 -13

janpeter commented 2026-08-16 20:16:25 +02:00

Owner

Copy link

Vervolg op #115.

Het probleem dat #115 zichtbaar maakte

Na de uitrol droegen de vloot-workers wel een application_name, maar de waarde was s4m-mcp:unknown-host:unknown-model — aanwezig en tóch niet toewijsbaar. S4M_SERVER, S4M_MODEL en SCRUM4ME_WORKER_INSTANCE_ID zijn in de worker-containers alle drie leeg en komen in de live compose helemaal niet voor.

Waarom die env-vars zetten de verkeerde oplossing is

Twee routes lagen voor de hand en zijn allebei onveilig:

S4M_SERVER + S4M_MODEL zetten. Die twee vormen samen een queue-adres, niet alleen een label. Krijgen de workers scrum4me-server + claude, dan draaien ze op het adres van een bestaande deelnemer en kan een job die queue_next aanroept berichten claimen die voor iemand anders bedoeld zijn. Stil, en pas merkbaar als een bericht nooit beantwoord wordt.

SCRUM4ME_WORKER_INSTANCE_ID per service pinnen. Dat is de registry-sleutel: registerWorker() gebruikt hem en workerHeartbeat doet claudeWorker.updateMany({ where: { token_id, instance_id } }). Een vaste waarde per service laat gescalede replica's (worker-idea draait op 2) als één worker registreren, met een heartbeat die meerdere rijen tegelijk raakt.

Wat deze PR doet

getInstanceId() bestond al en levert mcp-<hostname>-<pid>: uniek per proces, in een container is de hostname de container-id, en het vereist geen enkele nieuwe configuratie. applicationName() valt daarop terug wanneer er geen queue-identiteit is.

Resultaat: processen mét queue-identiteit houden het leesbare s4m-mcp:mac:claude; de vloot-workers krijgen s4m-mcp:mcp-<container>-<pid>, wat per proces te onderscheiden is en niet per service samenvalt.

Het commentaar in de module legt beide valkuilen vast, zodat de volgende lezer niet alsnog die env-vars zet.

Verificatie

• 11 tests (2 nieuw): fallback-vorm bij ontbrekende identiteit, whitespace-only identiteit, en expliciet dat twee processen op één host verschillende labels krijgen — die laatste bewaakt precies de reden waarom de instance-id niet per service gepind mag worden. 11/11 pass.
• tsc --noEmit: 0 fouten.
• vitest run: 183 passed, 3 skipped, geen failures.

Gedraaid met submodule geïnitialiseerd en prisma generate uitgevoerd, zoals CI het doet — zonder die stap geeft een verse clone honderden ruis-fouten die niets met de wijziging te maken hebben.

Vervolg op #115. ## Het probleem dat #115 zichtbaar maakte Na de uitrol droegen de vloot-workers wel een `application_name`, maar de waarde was `s4m-mcp:unknown-host:unknown-model` — aanwezig en tóch niet toewijsbaar. `S4M_SERVER`, `S4M_MODEL` en `SCRUM4ME_WORKER_INSTANCE_ID` zijn in de worker-containers alle drie leeg en komen in de live compose helemaal niet voor. ## Waarom die env-vars zetten de verkeerde oplossing is Twee routes lagen voor de hand en zijn allebei onveilig: **`S4M_SERVER` + `S4M_MODEL` zetten.** Die twee vormen samen een queue-**adres**, niet alleen een label. Krijgen de workers `scrum4me-server` + `claude`, dan draaien ze op het adres van een bestaande deelnemer en kan een job die `queue_next` aanroept berichten claimen die voor iemand anders bedoeld zijn. Stil, en pas merkbaar als een bericht nooit beantwoord wordt. **`SCRUM4ME_WORKER_INSTANCE_ID` per service pinnen.** Dat is de registry-sleutel: `registerWorker()` gebruikt hem en `workerHeartbeat` doet `claudeWorker.updateMany({ where: { token_id, instance_id } })`. Een vaste waarde per service laat gescalede replica's (`worker-idea` draait op 2) als één worker registreren, met een heartbeat die meerdere rijen tegelijk raakt. ## Wat deze PR doet `getInstanceId()` bestond al en levert `mcp-<hostname>-<pid>`: uniek per proces, in een container is de hostname de container-id, en het vereist **geen enkele nieuwe configuratie**. `applicationName()` valt daarop terug wanneer er geen queue-identiteit is. Resultaat: processen mét queue-identiteit houden het leesbare `s4m-mcp:mac:claude`; de vloot-workers krijgen `s4m-mcp:mcp-<container>-<pid>`, wat per proces te onderscheiden is en niet per service samenvalt. Het commentaar in de module legt beide valkuilen vast, zodat de volgende lezer niet alsnog die env-vars zet. ## Verificatie - **11 tests** (2 nieuw): fallback-vorm bij ontbrekende identiteit, whitespace-only identiteit, en expliciet dat twee processen op één host verschillende labels krijgen — die laatste bewaakt precies de reden waarom de instance-id niet per service gepind mag worden. **11/11 pass.** - `tsc --noEmit`: **0 fouten**. - `vitest run`: **183 passed, 3 skipped**, geen failures. Gedraaid met submodule geïnitialiseerd en `prisma generate` uitgevoerd, zoals CI het doet — zonder die stap geeft een verse clone honderden ruis-fouten die niets met de wijziging te maken hebben.

janpeter added 1 commit 2026-08-16 20:16:25 +02:00

fix(db): val terug op de presence-instance-id i.p.v. een unknown-label ... 1357a4bcdf

Na #115 droegen de vloot-workers wel een application_name, maar de waarde was
`s4m-mcp:unknown-host:unknown-model` — aanwezig en toch niet toewijsbaar.

De voor de hand liggende oplossing (S4M_SERVER/S4M_MODEL op de workers zetten)
is fout: die twee vormen samen een queue-ADRES. Krijgen de workers er een, dan
kunnen ze berichten claimen die voor een andere deelnemer bedoeld zijn, en dat
gebeurt stil.

SCRUM4ME_WORKER_INSTANCE_ID per service vastzetten is ook fout: dat is de
registry-sleutel waar registerWorker() en de heartbeat-updateMany op matchen,
dus gescalede replica's zouden als één worker registreren.

getInstanceId() levert al `mcp-<hostname>-<pid>`: uniek per proces, in een
container is de hostname de container-id, en het vereist geen enkele nieuwe
env-var. Daar valt de labelnaam nu op terug wanneer er geen queue-identiteit is.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

janpeter merged commit bafffaea61 into main 2026-08-16 20:18:48 +02:00

janpeter referenced this pull request from a commit 2026-08-16 20:18:49 +02:00

Merge pull request 'fix(db): val terug op de presence-instance-id i.p.v. een unknown-label' (#116) from fix/db-label-instance-fallback into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

janpeter/scrum4me-mcp!116

No description provided.