Feilsøking

Surveyen vises ikke

Komponenten er rendret, men ingenting vises på skjermen.

Sjekk 1: initialOpen er satt til false

Widgeten starter som standard åpen (initialOpen: true). Hvis dere har satt initialOpen: false, vises bare den minimerte knappen, og brukeren må åpne surveyen selv. Widgeten starter også minimert når den ikke får lagre, for eksempel når brukeren ikke har samtykket. Se Uten samtykke.

Med hideMinimizedButton: true vises heller ikke den minimerte knappen. Da ser ingen surveyen så lenge widgeten er minimert, og med initialOpen: false vises den aldri.

// Starter minimert
<LumiSurveyDock behavior={{ initialOpen: false }} />

// Starter åpen (standard)
<LumiSurveyDock behavior={{ initialOpen: true }} />

Sjekk 2: Surveyen er lukket eller besvart tidligere

Widgeten husker at brukeren har lukket eller svart på surveyen, og under utvikling kan dette henge igjen fra én sidelast til den neste.

Dere kan enten bruke storageStrategy: "none", så widgeten ikke lagrer noe, eller tømme localStorage og informasjonskapsler og laste siden på nytt.

// Under utvikling og testing
<LumiSurveyDock behavior={{ storageStrategy: "none" }} />

Sjekk 3: Ventetiden er ikke over

Etter at brukeren har lukket eller svart på surveyen, venter widgeten som standard 30 dager før den viser den igjen. Under utvikling er det enklest å bruke storageStrategy: "none" fra sjekk 2, så husker ikke widgeten at surveyen er lukket.

Ikke sett dismissCooldownDays: 0. Da går ventetiden aldri ut, og surveyen åpner seg ikke av seg selv igjen for den brukeren. Har brukeren lukket surveyen, vises bare den minimerte knappen. Har brukeren svart, er widgeten skjult for godt med hideAfterSubmit: true, som er standard.

Sjekk 4: CSS mangler

Uten CSS-importene kan elementer i widgeten bli usynlige. Se Layout virker tom lenger ned.

Widgeten virker ikke i Next.js App Router

Importer LumiSurveyDock fra @navikt/lumi-survey/client i en serverkomponent, eller start filen som bruker @navikt/lumi-survey, med "use client". Får dere feilen «Functions cannot be passed directly to Client Components», sender serverkomponenten en funksjon, for eksempel events eller en transport med submit. Flytt da widgeten til en egen fil med "use client". Se Next.js App Router.

Konsollen viser «[Lumi] The survey is not shown»

Widgeten vises ikke fordi transport mangler, har feil form eller endpoint er ugyldig. Meldingen sier hva som er feil. endpoint må starte med / og ligge på samme domene som siden, se Send svarene. En vanlig årsak er en miljøvariabel som mangler når appen bygges, slik at stien blir undefined/api/lumi/feedback.

Innsendingen feiler

Widgeten viser en feilmelding når innsendingen feiler. Med { endpoint } skriver widgeten også en melding som starter med [Lumi] Sending the survey to i konsollen, med status og årsak. Se ellers først i nettverksfanen i DevTools hvilken status kallet til appens backend får. Kallet videre til Lumi API vises ikke i nettleseren, så detaljene står i loggene til backenden. Ruten i backend-eksempelet sender statuskoden fra Lumi API videre til nettleseren.

Mangler en access policy, ser dere det på en av to måter: Tokenvekslingen feiler, eller kallet til Lumi API får tidsavbrudd.

Tokenvekslingen feiler

Loggen i backenden viser at tokenvekslingen feilet. I backend-eksempelet står det Tokenveksling feilet, og ruten svarer med 500. Kallet til Lumi API blir ikke sendt.

Sjekk dette:

1. Mottakeren har appen deres som inbound. Uten regelen får ikke appen veksle token til mottakeren. Tilgangen gjelder først når PR-en er merget og mottakeren er deployet. Se Mottakeren (inbound).
2. LUMI_AUDIENCE hører til samme mottaker som LUMI_API_HOST. Se miljøvariablene.
3. Nais-manifestet har tokenx.enabled: true for TokenX eller azure.application.enabled: true for Entra ID.
4. Har appen både TokenX og Entra ID slått på, returnerer requestOboToken alltid en feil. Bruk requestTokenxOboToken eller requestAzureOboToken.

Kallet til Lumi API får tidsavbrudd

fetch mot Lumi API får ikke svar. Ruten i backend-eksempelet gir opp etter åtte sekunder, logger Lumi API svarte ikke og svarer 504. Uten en slik grense feiler fetch først etter en stund, ofte med fetch failed i loggen. Som regel slipper ikke nettverket i Nais kallet gjennom, fordi appen mangler outbound-regel mot mottakeren.

Sjekk dette:

1. Finn riktig mottaker i tabellen over mottakere.

2. Appen deres har en outbound-regel mot denne mottakeren. For direkte kall til lumi-api:

   spec:
     accessPolicy:
       outbound:
         rules:
           - application: lumi-api
             namespace: team-esyfo

   For Entra ID i dev med trygdeetaten.no-tenant:

   spec:
     accessPolicy:
       outbound:
         rules:
           - application: lumi-submission-proxy
             namespace: team-esyfo

3. LUMI_API_HOST peker på den samme mottakeren: http://lumi-api.team-esyfo eller http://lumi-submission-proxy.team-esyfo.

Statuskoder fra Lumi API

Kommer kallet fram, svarer Lumi API eller proxyen med en av disse kodene. Feilmeldingen i svaret står i loggen når backenden logger den, slik eksempelet gjør.

Status	Hva det betyr	Hva dere gjør
400	Payloaden er ugyldig, for eksempel fordi backenden sender hele submission og ikke submission.transportPayload.	Send transportPayload videre uendret.
401	Tokenet mangler, er utløpt eller har feil utsteder. Ruten i eksempelet svarer selv 401 når brukerens token mangler eller er ugyldig, så sjekk loggen i backend for å se hvem som svarte. Et TokenX-token til /api/azure/v1/feedback gir 401, og det samme gjør et Entra ID-token til /api/tokenx/v1/feedback.	Bruk host, audience og sti fra samme miljøblokk.
404	Host og sti passer ikke sammen, for eksempel /api/tokenx/v1/feedback sendt til lumi-submission-proxy, som bare har endepunktet for Entra ID.	Bruk host, audience og sti fra samme miljøblokk.
409	Surveyen er endret på en måte som ikke passer med definisjonen Lumi API har lagret for surveyId. Svaret er ikke lagret.	Se Hvis API-et svarer med 409.
411	Proxyen fikk et kall uten headeren Content-Length. Gjelder bare trygdeetaten.no i dev.	Send hele payloaden i ett kall med Content-Length, ikke som en strøm.
413	Payloaden er større enn 1 MB.	Send bare transportPayload.
429	Appen har sendt mer enn 100 svar på ett minutt, eller samme bruker mer enn 15. I dev deler alle apper i trygdeetaten.no én grense gjennom proxyen. Grensen gjelder et helt minutt, så widgeten prøver ikke på nytt av seg selv.	Vent et minutt. Skjer det ofte, spør i #lumi på Slack.
500	Feil i Lumi API eller proxyen.	Spør i #lumi.
502	Proxyen fikk ikke sendt svaret videre til Lumi API. Gjelder bare trygdeetaten.no i dev.	Spør i #lumi.
503	Texas i Nais svarte ikke, så Lumi API eller proxyen fikk ikke kontrollert tokenet. Med meldingen «Databasen svarer ikke akkurat nå» svarte databasen ikke i tide. Svaret er ikke lagret. Widgeten prøver én gang til av seg selv, se Tidsgrense og nytt forsøk.	Prøv igjen litt senere. Skjer det ofte, spør i #lumi.

Ingen data i dashboardet

Widgeten viser takkesiden, men svarene dukker ikke opp i dashboardet.

Sjekk dette:

1. Med egen transport kaster transport.submit en feil når backenden svarer med feil. Widgeten viser takkesiden så lenge submit ikke kaster, også når kallet feilet. Sjekk response.ok, slik eksempelet gjør, eller bruk { endpoint }, som gjør det selv.

2. Backenden svarer med 2xx bare når Lumi API gjorde det. Se i nettverksfanen i DevTools hvilken status kallet til appens backend får, og i loggene til backenden hva Lumi API svarte.

3. Sjekk at dere bruker riktig endepunkt i Lumi API:

   • sluttbrukere: POST /api/tokenx/v1/feedback
   • interne apper: POST /api/azure/v1/feedback

4. Sjekk at dere ser i riktig miljø. Svar sendt fra dev vises i dashboardet i dev.

5. Sjekk at dere ser på riktig surveyId i dashboardet. Dashboardet filtrerer på surveyId.

Layout virker tom

Widgeten vises, men uten stiler: ingen farger, rar layout og elementer som overlapper. Da mangler minst én av CSS-importene. Begge må være med:

import "@navikt/ds-css";                 // Grunnstilene fra Aksel
import "@navikt/lumi-survey/styles.css"; // Stilene til widgeten

Sjekk rekkefølgen på importene

Importer @navikt/ds-css før @navikt/lumi-survey/styles.css.

Widgeten husker ikke at surveyen er lukket

Widgeten starter minimert ved hver sidelast, også før brukeren har lukket surveyen. Det betyr at widgeten ikke får lagre at surveyen er lukket eller besvart. I versjoner før 2.3.0 åpner surveyen seg ved hver sidelast.

I interne apper som Modia og fagsystemer mangler vanligvis Nav-dekoratøren, som standardstrategien consent trenger. Widgeten skriver da en advarsel som begynner med [Lumi] i konsollen. Sett storageStrategy til localStorage, så åpner surveyen seg av seg selv og widgeten husker lukkingen:

<LumiSurveyDock
  behavior={{ storageStrategy: "localStorage" }}
/>

På nav.no husker widgeten lukkingen bare når brukeren har samtykket til surveys, og dekoratøren tillater nøkkelen widgeten lagrer under. Uten samtykke i Lagring viser hvordan dere sjekker dette i nettleseren. Widgeten kaller onDismissalPersistFailed når den ikke får lagret lukkingen. Se Events.

Validering feiler uventet

Brukeren får valideringsfeil selv om spørsmålene er besvart.

Har dere required: true på spørsmål som skjules med visibleIf? Skjulte spørsmål hoppes over i valideringen, men sjekk at betingelsen skjuler spørsmålet når dere forventer det.

Med onValidationFailed ser dere hvilke spørsmål som mangler svar:

<LumiSurveyDock
  events={{
    onValidationFailed: (missing) => {
      console.log("Mangler svar:", missing);
    },
  }}
/>

Mer hjelp

Spør i #lumi på Slack. Feil i Lumi kan dere melde på GitHub. Alle props er beskrevet i Props-referansen. Problemer med utseendet er beskrevet i Styling, og problemer med flyten i Vis bare relevante spørsmål.