Projects and Bugs: Team bug report

Team bug report
English: Write in your chat group. Tell them you have found a bug in the system. Explain shortly what happens and that you will try to fix it.
Svenska: Skriv i er chattgrupp. Berätta att du har hittat ett fel i systemet. Förklara kort vad som händer och att du ska försöka lösa det.

Hej #backend-team!

Hej #backend-team!

Alex här från NordTech Solutions AB i Stockholm — jag skriver i vår chattgrupp för att berätta att jag har hittat ett fel i systemet.

Det är inte en akut säkerhetsincident, men det påverkar användare som försöker spara rapportinställningar i Ventilation Nord-portalen.

Jag upptäckte buggen under morgon-test innan standup när jag körde regression mot staging efter Sofia Nilssons deployment igår kväll.

Vad som händer: när en användare ändrar tidsintervall för veckostatistik och klickar Spara får de felmeddelande 500 utan att data faktiskt sparas i PostgreSQL.

Frontend i React visar en generisk röd banner, men API:t svarar med Internal Server Error och loggen pekar på validering i rapportmodulen.

Stacktrace visar NullPointerException-liknande beteende i Python-tjänsten — ett fält som borde vara optional hanteras som obligatoriskt efter schemaändring.

Jag har reproducerat felet tre gånger med samma steg: logga in som testanvändare, öppna dashboard, byt från sju dagar till trettio dagar, klicka Spara.

Markus Berg, du ändrade rapport-API förra sprinten — jag misstänker att migrationen saknar default för ett fält som frontend inte skickar längre.

Sofia bekräftade att deployment till staging gick rent; inga alerts i Grafana före mitt test, så buggen verkar logisk snarare än infrastruktur.

Anna Berg, projektledare, behöver veta att ticket NTS-2901 kan blockera demo för Ventilation Nord AB om vi inte fixar innan torsdag.

Jag ska försöka lösa det — planen är att isolera valideringsregeln, lägga till test i pytest och pusha fix på feature branch idag.

Första steget: jämföra request payload mot OpenAPI-spec och se vilka fält backend förväntar sig efter gårdagens merge till main.

Andra steget: skriva ett test som reproducerar 500-svaret så att vi inte mergar samma regression igen utan att CI fångar det.

Tredje steget: om fixen är liten tar jag PR direkt till Markus för review; om den är större bokar jag parprogrammering i eftermiddag.

Jag postar uppdateringar i denna tråd och i #notifiering-debug om jag behöver hjälp med databasschema eller consumer-köer.

Kort förklaring till kollegor som inte rör rapportmodulen: användare kan läsa data men inte spara nya filter — läsning fungerar, skrivning failar.

Ingen produktionsdata är korrupt enligt mina tester; felet sitter i applikationslagret innan commit till databasen slutförs.

Jag har redan skapat Jira-bug NTS-2901 med steg för att reproducera, loggutdrag och länk till Grafana-panel för error rate.

Severity: medium — påverkar en del av portalen men inte hela inloggning eller betalningsflöde som vi prioriterade högre.

Om någon ser samma fel i produktion, pinga mig direkt — jag håller staging och prod diff i ett dokument under docs/bugs/rapport-save-2026-06-30.txt.

Markus, om du har två minuter: kolla om fältet interval_type ska vara required i Pydantic-modellen efter din PR från sprint två.

Sofia, ingen rollback behövs ännu — staging är stabil för andra moduler; jag fixar forward om valideringen är roten.

Teamet behöver inte panik: jag har hittat felet tidigt, förstår ungefär var det sitter och har en konkret plan att försöka lösa det idag.

Det här är exakt varför vi kör regression efter varje deployment — utan morgon-test hade buggen kunnat ligga kvar till kunddemo.

Jag ska försöka lösa det innan lunch om valideringsfixen räcker; annars uppdaterar jag här efter standup med ny tidsplan.

Om frontend behöver ändras också kopplar jag in UI-teamet, men just nu ser det som backend-validering som rejectar partial payload.

Loggarna från 08.15 till 08.45 visar tolv failed requests från staging-test — alla samma endpoint POST /api/reports/settings.

Response time är normal; felet är funktionellt, inte prestanda — viktigt att skilja så vi inte optimerar fel lager.

Jag dokumenterar root cause i Confluence när fixen är merged enligt vår rutin för återkommande buggar i rapportmodulen.

Tack för att ni läser — transparens i chattgruppen hjälper hela sprinten när buggar dyker upp mitt i andra tickets.

Hör av er om ni sett liknande i andra endpoints efter schemaändring — mönster kan upprepas om samma migration-mall användes.

PS: Jag har inte skickat kundmejl ännu — Anna och jag synkar först om kunden behöver informeras innan fix är live.

PPS: Branch för fix kommer att heta bugfix/nts-2901-report-settings-validation om någon vill följa commits live.

Uppdatering planeras cirka 11.00: antingen fix merged eller tydlig blocker med detaljer om vad jag behöver hjälp med.

Vi ses på standup — jag kan demonstrera felet på delad skärm om det hjälper teamet förstå scope innan vi prioriterar.

Det är bra att vi hittar buggar i teamet tidigt — jag tar ansvar för att försöka lösa detta och håller er uppdaterade i chattgruppen.

Om du jobbar i rapportmodulen: dubbelkolla om dina lokala tester fortfarande passerar efter gårdagens merge — dela resultat i tråden.

Jag kopplar in frontend-teamet endast om request payload faktiskt saknar fält — just nu pekar allt på backend-validering efter schemaändring.

Error rate i Grafana steg från noll till tolv failed requests under mitt test — inget kontinuerligt flöde, men tillräckligt för att bekräfta buggen.

Ventilation Nord AB behöver inte veta ännu enligt Anna — vi informerar kund bara om felet finns i produktion eller omverkar demo på torsdag.

Markus, din input på Pydantic-modellen vore guld — pinga mig om du ser notification i #backend-team innan standup om du hinner läsa tråden.

Alex Kowalski, backend-utvecklare, NordTech Solutions AB, Stockholm.

/Alex