Operative Kafka-kontrakter

Dette er det kildeverifiserte utkastet til #212. Det skiller mellom hva dagens kode kan bevise og hva teamet fortsatt må beslutte. Alle operative topic-kontrakter står fortsatt som proposed, og Kontrollrommet viser derfor IKKE EVALUERT.

Airflow er bare ført som ekstern leser. Team eSyfo eier ikke driften eller sluttutfallet der. Consumer-lag brukes som diagnostikk, aldri som eneste pagergrunnlag.

Team eSyfo eier topicet og de interne stegene. Produsenten eier frem til broker-ACK, og intern konsument eier terminal behandling. Ved ekstern handoff overtar mottakerteamet; en ende-til-ende-kontrakt må avtales sammen.

De ti topicene

Ingen av topicene er en heartbeat. Nulltrafikk er derfor ikke i seg selv en feil, men akseptabelt tidsvindu og nødvendige støttebevis må godkjennes per topic. Tabellen viser hvorfor null kan oppstå; den vedtar ikke nulltrafikkpolicyen.

Topic og aktiv rute	Formål og terminal semantikk	Riktig helsesignal og nåværende gap
aapen-syfo-oppfolgingsplan-lps-nav-v2 lps-oppfolgingsplan-mottak → ispersonoppgave	Oppfølgingsplaner som krever NAV-bistand. Produsenten kaller asynkron send, men dagens success-telling beviser ikke broker-ACK. Ekstern konsuments sluttutfall og retry er ukjent.	Broker-ACK/-feil, reconciliation fra kvalifisert plan til event og ekstern freshness. Bekreft aktiv consumer group og sluttutfall med team iSyfo.
budstikka.v1 syfo-oppfolgingsplan-backend → syfo-budstikka	Varseldispatch med stabil eventId, durable outbox/inbox og deduplisering. Produsentens SENT betyr Kafka-ACK; Budstikkas delivery-SENT betyr at neste kanal har akseptert handoffen, ikke at brukeren har lest varselet.	Produsentens forfalte outbox, retries og brokerutfall overvåkes separat fra Budstikkas inbox, delivery-kø, worker-ferskhet og terminale utfall. Kafka-lag er kun transportdiagnostikk.
dinesykmeldte-hendelser-v2 esyfovarsel + syfo-budstikka + Flex → dinesykmeldte-backend	Oppretter eller ferdigstiller hendelser for arbeidsgiverflaten. Terminal suksess er lagret hendelsestilstand. Behandlingsfeil restarter konsumenten; ingen DLQ er bevist. Budstikka er manifestert og implementert produsent, mens esyfovarsel fortsatt er legacy-produsent.	Behandlede utfall og freshness/eldste ubehandlede; group-lag kun som diagnostikk. Skill produsent og eventtype under migrering, og sammenlign aggregert trafikk og utfall før cutover uten å innføre per-hendelse-regnskap.
kartleggingssporsmal-svar meroppfolging-backend → ismeroppfolging	Brukerens kartleggingssvar lagres før en asynkron Kafka-send. Callback-feil logges, men verken returneres til kalleren eller forsøkes på nytt; lagret svar kan derfor mangle event. Ekstern sluttbehandling er ukjent.	Broker-ACK/-feil og reconciliation mellom lagrede svar og events, deretter ekstern freshness. Bekreft aktiv consumer group og sluttutfall med team iSyfo.
sen-oppfolging-svar meroppfolging-backend → ismeroppfolging	Brukerens svar lagres før synkron publish. Publish-feil går tilbake til HTTP-kallet, men et nytt forsøk kan avvises fordi svaret allerede finnes. Ingen durable outbox er bevist.	Reconciliation lagret svar → Kafka-ACK → ekstern behandling. Avklar reparasjon/deduplisering og eksternt sluttutfall.
sen-oppfolging-varsel meroppfolging-backend → ismeroppfolging	Planlagt jobb kjører hver time 09–17; en kjøring kan legitimt produsere null. Koden publiserer etter dokument/varselarbeid, mens manifestteksten beskriver en sendekommando. Service-laget kan svelge publish-feil slik at jobben fjerner retrydatoen.	Siste forventede jobbkjøring, antall kvalifiserte/publiserte/avviste/feilede og reconciliation. Avklar først om eventet betyr «send» eller «allerede sendt», og etabler reparerbar feilsemantikk.
syfo-narmesteleder-leesah esyfo-narmesteleder → dinesykmeldte-backend	Team-eid, kompaktert kopi av nærmeste-leder-endringer. Broen lagrer, sender med broker-ACK og committer legacy-offset; feil gir batch-retry og kan duplisere. Ugyldige records droppes. Tombstones videresendes, mens dagens Dinesykmeldte-konsument ikke har en synlig null-guard.	Eksakt group-progresjon, alder på siste domeneevent, utfall per record og reconciliation av aktiv ledertilstand. Avklar tombstone, duplikat og expected-drop-semantikk.
sykepengedager-informasjon-topic sykepengedager-informasjon → meroppfolging-backend	Beregnet sykepengeinformasjon. Produsenten venter på ACK og lagrer SENT eller SENDING_FAILED; ingen automatisk resend av feiltabellen er bevist.	Eldste SENDING_FAILED, ACK-/feilutfall, downstream-freshness og reconciliation. Avklar reparasjon og terminalt konsumentutfall.
sykepengedager.infotrygd.v1 Infotrygd/GoldenGate → sykepengedager-informasjon	Kompaktert input fra en team-eid AivenApplication med ekstern datakilde. Konsumenten acknowledger etter vellykket prosessering, men fanger feil uten ack eller rethrow; DLQ er ikke bevist.	Eksakt consumer-progresjon, eldste ubehandlede endring og reconciliation mot lagret tilstand. Bekreft retryoppførsel og teknisk eier for kilden.
varselbus flere produsenter → esyfovarsel	Legacy varselbus. Konsumenten committer også etter behandlingsfeil; Kafka-inputen retries derfor ikke. Enkelte kanalfeil lagres og retries senere i databasen. syfooppfolgingsplanservice ble fjernet fra forventet produsenttopologi etter tjenestestoppen 2. september 2026.	Per produsent og eventtype: kvalifisert → akseptert → sendt, expected drop eller teknisk/permanent feil; i tillegg eldste retry. Ikke bland migrert og legacy trafikk i én rate.

Kildegrunnlaget er manifest og implementasjon på default branch 29.–30. august 2026: LPS, Budstikka, oppfølgingsplan, Dine sykmeldte, Mer oppfølging, nærmeste leder, sykepengedager og esyfovarsel. ACL beviser tilgang, ikke at en ekstern consumer group faktisk er aktiv.

Varsling: separat operativt ansvar

Observability-baselinen innfører ikke en egen per-hendelse-kvittering eller avstemming mellom produsenter og syfo-budstikka.

• Produsenten overvåker sin durable outbox frem til broker-ACK: forfalt antall, eldste alder, retries og terminalt ACK eller forventet kansellering.
• Kafka-lag brukes som diagnostikk for transportleddet, ikke alene som brukerimpact eller pagergrunnlag.
• Budstikka overvåker sin durable inbox og delivery-kø: forfalt antall, eldste alder, legitim WAIT separat, terminale utfall og worker-ferskhet.
• event_id kan brukes til manuell loggkorrelasjon, men aldri som metrics-label eller krav om operativt per-hendelse-regnskap.
• En leveringskvittering tilbake til produsenten er et eventuelt separat funksjonelt behov, for eksempel en status-topic.

Det finnes derfor ingen vedtatt 5/5/30-frist eller egen 28-dagers cross-component-shadow. Status per 31. august 2026: Oppfølgingsplan-PR #451 er merget og deployert i dev og prod; den har etablert produsentens utgående varselkø som en egen ansvarsflate. #454 ligger til review og foreslår at de tre køtilstandsreglene bare bruker ferske snapshots, samt en egen warning når snapshotet er gammelt eller mangler. Den tidligere Budstikka-PR #266 er lukket. #268 er godkjent og har egne kø- og ferskhetssignaler; #269 innfører et stabilt, label-fritt CAS-konfliktsignal og venter på human review. #264 bygger på #269 og foreslår en varig feilkø. Ved vanlig squash-merge av #269 må main deretter flettes inn i #264-grenen, slik at siste review og checks gjelder en ren #264-diff. Ingen av signalene betyr at sluttbrukeren har lest varselet.

Gjenstående beslutninger

1. Godkjenn egne frister og nulltrafikkvilkår for produsentens outbox og Budstikkas inbox/delivery-kø. Eksisterende 15-minutters lag-alert er fortsatt operasjonell hygiene, ikke brukerimpact.
2. Godkjenn nulltrafikkpolicy for de øvrige topicene: tidsvinduet og hvilke signaler for forventet jobb/runtime, forfalt arbeid og retry-/feilbacklog som samtidig må være friske.
3. Klassifiser tvilstilfellene: manglende kilde, leder eller e-post, malformed records og tombstones som expected drop eller teknisk/product failure.
4. Bekreft aktive eksterne consumer groups, terminalt utfall og reparasjonsansvar med team iSyfo. Airflow forblir utenfor eSyfos driftsscope.
5. Godkjenn migrasjon per produsent og eventtype. Cutover krever fravær av gammel trafikk for typen, stabil produsent-outbox, stabile Budstikka-køer, ingen voksende terminalfeil og verifisert rollback/runbook.
6. Velg observasjonsperiode og terskler per signal. For alle topicer krever paging fortsatt egen impactterskel, shadow-evidens og beslutning i #217; før dette er signalene diagnostikk.