Sprints and Meetings: Ask developer for help

Ask developer for help
English: Write to a coworker. You are stuck on a problem in the code. Ask if the coworker has time to look at it with you this afternoon.
Svenska: Skriv till en kollega. Du har fastnat på ett problem i koden. Fråga om kollegan har tid att titta på det med dig i eftermiddag.

Hej Markus!

Hej Markus!

Alex här från #backend-team — jag skriver till dig som kollega på NordTech Solutions AB här i Stockholm.

Jag har fastnat på ett problem i koden och behöver lite hjälp innan sprinten tar slut på fredag.

Det är inte en akut produktionsincident, men ticketen blockerar min andra story i Jira och jag vill inte lämna den halvfärdig över helgen.

Problemet sitter i vår notifieringstjänst: när en webhook från betalningsmodulen returnerar timeout får vi ibland dubbla events i kön.

Jag har reproducerat felet lokalt med Docker Compose och seed-data som Sofia Nilsson tipsade om, men jag ser inte var dubbelhanteringen sker.

Stacktrace pekar mot en asynkron consumer i Python, men loggarna visar att samma event_id processas två gånger med fem sekunders mellanrum.

Jag har redan kollat idempotency-nyckeln i PostgreSQL — raden finns, men consumer verkar inte respektera unique constraint vid retry.

Markus, du byggde originalversionen av den här kölogiken förra kvartalet, så ditt öga på arkitekturen skulle spara mig timmar av trial and error.

Jag undrar om du har tid att titta på det med mig i eftermiddag — kanske en timme parprogrammering räcker för att hitta rotorsaken.

Jag är flexibel mellan 13.00 och 16.30 om du har lucka efter lunch eller efter daily standup.

Vi kan sitta vid skrivbordet i backend-rummet eller ta det i Teams om du jobbar remote idag — jag anpassar mig helt.

Jag har förberett en kort sammanfattning i Slack-tråden #notifiering-debug med länk till branch, loggar och steg för att reproducera.

Branch: feature/fix-webhook-double-event, pushad igår kväll med två commits som isolerar felet utan att röra produktionskonfiguration.

I tråden finns också skärmdump från Grafana där du ser dubbla spikes vid exakt samma payload_hash — det känns som en race condition.

Jag har läst vår intern dokumentation om event-driven design, men det här edge case verkar inte täckas i Confluence-sidan du skrev i mars.

Sofia sa att staging inte visar samma mönster, vilket gör det svårare — kanske latency eller olika retry-policy i miljöerna.

Anna Berg, projektledare, vet att jag jobbar på ticketen och är okej med att jag ber om hjälp — hon föreslog faktiskt att jag kontaktar dig.

Sprintmålet för den här veckan inkluderar stabil notifiering inför demo för kunden Ventilation Nord AB på torsdag, så timingen är lite pressad.

Jag vill inte att du tar över ticketen — jag vill bara förstå var i flödet dubbelprocessningen sker så att jag kan fixa och skriva tester.

pytest-tester för happy path finns redan; jag behöver hjälp att designa ett test som simulerar timeout och retry utan att flakiness förstör CI.

Om eftermiddag inte passar, funkar också tidig morgon imorgon bitti innan standup, men i eftermiddag vore idealiskt så jag kan pusha fix samma dag.

Jag har blockat ut två timmar i kalendern under titeln parprogrammering — du kan boka in dig på den om det underlättar.

Kort om kontext: vi migrerade till ny message broker i sprint två och jag misstänker att ack-timing ändrats, men jag vill inte spekulera utan dig.

Markus, du svarade snabbt i chatt när Sofia hade DevOps-frågor förra veckan — jag hoppas att du har samma energi för en kodfråga nu.

Jag lovar att inte dra ut på mötet: om vi inte hittar något på fyrtio minuter tar jag paus och dokumenterar hypoteser för nästa pass.

Efter vår session kan jag uppdatera README i notifieringsmodulen om vi hittar något som andra utvecklare bör känna till.

Jag skickar inte bara ett vagt jag har fastnat — jag vill visa att jag gjort research innan jag ber om din tid, som respekt för din kalender.

Felmeddelandet i konsolen är inte särskilt hjälpsamt: ProcessingError utan detaljer, vilket gör att jag behöver någon som känner historiken.

Jag har jämfört med main branch och diffen är liten, så regressionen är troligen i hur vi hanterar partial failure efter timeout.

Om du föredrar att jag skickar en screen recording först kan jag spela in fem minuter i eftermiddag innan vi ses — säg bara till.

Teamet pratar ofta om att fråga tidigt är smart i sprint — det är därför jag skriver nu istället för att sitta tyst till retrospektiven.

Jag vet att du har egen ticket kring API-versionering, så jag förstår om du bara har trettio minuter — även det hjälper enormt.

Vi kan börja med att du läser min branch i GitHub och kommenterar i PR om det är smidigare än live-session första steget.

PR är draft och inte redo för review ännu, men länken finns i Slack-tråden om du vill skumma innan vi ses.

Jag har också exporterat relevanta loggrader till en textfil i repot under docs/debug/double-event-2026-06-23.txt för enkel läsning.

Parprogrammering med dig förra veckan på user-settings-endpointen gav mig mycket — samma format funkar perfekt för det här problemet.

Om du sitter nära kaffemaskinen efter lunch kan jag komma förbi med laptop — eller vi delar skärm i Teams med dig som driver debugger.

Jag ska ta med frågor listade på papper så vi inte glömmer att kolla retry-config, consumer group offset och idempotency-tabellen.

Eftermiddag passar många i teamet bättre än kväll — därför frågar jag specifikt om du har tid i eftermiddag att titta på koden tillsammans.

Svar i tråden eller här i DM funkar — jag håller mig till Slack så att Sofia ser om vi behöver staging-access under sessionen.

Tack för att du läser — jag uppskattar verkligen att seniora utvecklare på NordTech delar tid när någon har fastnat i koden.

Hör av dig om eftermiddag funkar, eller föreslå en annan lucka idag eller imorgon som passar din sprintplanering bättre.

PS: Jag har redan tagit lunch så jag är tillgänglig från 12.45 om du vill börja tidigt — ingen stress om du behöver mer tid efter möten.

PPS: Ticket-nummer i Jira är NTS-2847 om du vill läsa acceptance criteria innan vi ses — det förklarar varför dubbla events är kritiskt.

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

/Alex