synops/docs/erfaringer/access_propagering.md
vegard f52d23de54 Fix: synops-respond propagerer access til chat-deltakere
Bot-svar var usynlige fordi node_access ikke ble propagert.
Alle deltakere i chatten (owner/member_of) får nå reader-access
til svar-noder. Erfaringsnotat dokumenterer mønsteret.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-20 06:06:58 +00:00

1.6 KiB

Erfaring: Access-propagering for chat-meldinger (mars 2026)

Problemet

Bot-svar i chatter var usynlige for brukere. Meldingene ble skrevet til PG, men brukerne hadde ingen node_access-rad for dem. Frontend filtrerte dem bort som "hidden".

Rotårsak

synops-respond (og chat-reply.sh) opprettet svar-noder med visibility: 'hidden' og belongs_to-edge til chatten, men propagerte ikke node_access til chat-deltakerne.

Maskinrommets intention-system (create_node med context_id) propagerer access automatisk. Men verktøy som skriver direkte til PG må gjøre det selv.

Fiks

Etter INSERT av belongs_to-edge, propager access til alle deltakere i chatten:

INSERT INTO node_access (subject_id, object_id, access, via_edge)
SELECT e.source_id, $reply_id, 'reader', $edge_id
FROM edges e
WHERE e.target_id = $communication_id
AND e.edge_type IN ('owner', 'member_of')
ON CONFLICT DO NOTHING

Lærdommer

  1. Alle som skriver til PG direkte må propagere access. Maskinrommets intention-system gjør det automatisk, men CLI-verktøy, scripts og direkte INSERT gjør det ikke. Det er lett å glemme — og resultatet er usynlige noder.

  2. Test med en annen bruker. Utvikleren ser egne noder uansett (created_by). Buggen er bare synlig for andre deltakere i chatten.

  3. WebSocket-filtrering forsterker problemet. Selv om noden er i PG, filtrerer portvokteren den bort for brukere uten access. Dobbel usynlighet.

Påvirket kode

  • tools/synops-respond/src/main.rs — fikset
  • scripts/chat-reply.sh — hadde allerede propagering
  • Alle andre verktøy som skriver noder med belongs_to-edge bør sjekkes