[ISS-10] Presence-drainstempel van de MCP faalt stil: scrum4me_web_runtime mag niet schrijven in agent_presence #168

New issue

Open

opened 2026-09-27 22:20:33 +02:00 by janpeter · 0 comments

janpeter commented

2026-09-27 22:20:33 +02:00

Owner

Beheerd door Scrum4Me — wijzigingen hier worden overschreven. Bron: https://thuis.jp-visser.nl/issues/cmuk9fr8g001wjfbkopnslcrk

Status: new · Severity: s4_minor · Gemeld door: max2:claude · Occurrences: 1 (laatst: 2026-09-27T20:17:35.392Z) · Aangemaakt: 2026-09-27T20:17:35.392Z

Registratie

Gevonden bij de inventaris voor max2 ISS-13 (ProductDoc max2 SPECS/worker-db-access-inventory), 2026-09-27, read-only.

Wat er gebeurt

stampDrainPresenceBestEffort (src/queue/presence.ts:193-210, commit c20688e) doet INSERT INTO agent_presence (server, model, session_last_drain_at, updated_at) … ON CONFLICT (server, model) DO UPDATE SET session_last_drain_at = now(), updated_at = now(). Hij wordt aangeroepen vanuit queue_done en queue_wait_reply.
De MCP verbindt als scrum4me_web_runtime. Die rol heeft op agent_presence alleen SELECT. Schrijfrechten heeft alleen s4m_queue, per kolom verleend over 11 kolommen (information_schema.column_privileges op 154).
De try/catch slikt de permission-fout in, zodat de stempel nooit landt.

Gevolg: session.last_drain_at in queue_presence / s4m-queue presence wordt voor MCP-sessies niet bijgewerkt; max2:claude staat op 2026-09-25, ondanks vele MCP-claims daarna. Presence is informatie en nooit een gate, dus er faalt geen werk. Wel leest de "laatste drain" misleidend, en de fout staat alleen in de MCP-stderr.

Oplossingsrichtingen (besluit hoort in het DB-toegangsbeleid, Scrum4Me-profiel)

a) Kolomcontract voor de MCP-rol: INSERT op (server, model, session_last_drain_at, updated_at), UPDATE op (session_last_drain_at, updated_at). Dit is hetzelfde voorstel als voor de nieuwe scrum4me_worker in max2 ADR/worker-db-rol, punt 3.
b) De drain-stempel uit de MCP halen, zodat presence alleen via het queue-pad loopt.
Log de fout minstens één keer zichtbaar met een reden, zodat het niet stil blijft.

Geen secrets in dit issue.

Onderzoek

Nog geen onderzoek.

Oplossing

Nog geen oplossing.

> Beheerd door Scrum4Me — wijzigingen hier worden overschreven. Bron: https://thuis.jp-visser.nl/issues/cmuk9fr8g001wjfbkopnslcrk Status: new · Severity: s4_minor · Gemeld door: max2:claude · Occurrences: 1 (laatst: 2026-09-27T20:17:35.392Z) · Aangemaakt: 2026-09-27T20:17:35.392Z ## Registratie Gevonden bij de inventaris voor max2 ISS-13 (ProductDoc max2 SPECS/worker-db-access-inventory), 2026-09-27, read-only. **Wat er gebeurt** - `stampDrainPresenceBestEffort` (src/queue/presence.ts:193-210, commit c20688e) doet `INSERT INTO agent_presence (server, model, session_last_drain_at, updated_at) … ON CONFLICT (server, model) DO UPDATE SET session_last_drain_at = now(), updated_at = now()`. Hij wordt aangeroepen vanuit queue_done en queue_wait_reply. - De MCP verbindt als `scrum4me_web_runtime`. Die rol heeft op `agent_presence` alleen SELECT. Schrijfrechten heeft alleen `s4m_queue`, per kolom verleend over 11 kolommen (information_schema.column_privileges op 154). - De try/catch slikt de permission-fout in, zodat de stempel nooit landt. **Gevolg:** `session.last_drain_at` in `queue_presence` / `s4m-queue presence` wordt voor MCP-sessies niet bijgewerkt; max2:claude staat op 2026-09-25, ondanks vele MCP-claims daarna. Presence is informatie en nooit een gate, dus er faalt geen werk. Wel leest de "laatste drain" misleidend, en de fout staat alleen in de MCP-stderr. **Oplossingsrichtingen (besluit hoort in het DB-toegangsbeleid, Scrum4Me-profiel)** - a) Kolomcontract voor de MCP-rol: INSERT op (server, model, session_last_drain_at, updated_at), UPDATE op (session_last_drain_at, updated_at). Dit is hetzelfde voorstel als voor de nieuwe `scrum4me_worker` in max2 ADR/worker-db-rol, punt 3. - b) De drain-stempel uit de MCP halen, zodat presence alleen via het queue-pad loopt. - Log de fout minstens één keer zichtbaar met een reden, zodat het niet stil blijft. Geen secrets in dit issue. ## Onderzoek _Nog geen onderzoek._ ## Oplossing _Nog geen oplossing._

janpeter added the

severity/s4

label

2026-09-27 22:20:33 +02:00