gofri Why two g's? When I was a kid my grandma called me Gofri, and the family picked it up. She said the G hard, almost twice, so I write it twice.
production

Batch chat recovery

for
Batch, via eagerWorks
when
2023
Problem
Customers felt the chat was broken and were leaving it, so adoption was low.
My contribution
Investigated a broken chat, found the causes and shipped fixes behind a staged rollout.
Result
Diagnosed in one week, fixed over a two-week sprint, rolled out in stages.
Status
production · 2023

1 weekto diagnose, then a two-week fix sprint

what I foundReproducing the chat showed three separate problems, not one.

The chat feels broken

Here is the receipt. receipt.pdf attachment gone +1
Thanks, checking it now.
refetching the whole thread…
loading media
Any news?↕ view jumped
  1. Reacting to a message wipes its attachment.The attachment survives a reaction.
  2. The view jumps while you read.Your place holds; a button offers the new messages.
  3. Every update refetches the whole thread.Media loads lazily, with a retry.
  1. internal
  2. blue/green
  3. all users
The same conversation, before and afterreconstruction, illustrative

play it

One reaction, one lost attachment

Here is the receipt. receipt.pdf
Thanks, checking it now.

After the fix, a reaction updates the message atomically and the attachment survives.

simulated thread, illustrative React to the message, with and without the fix

diagnosis

Three symptoms, three causes

  1. Reacting to a message wipes its attachment.A message update let a reaction overwrite the attachment.Updates became atomic.
  2. The view jumps while you read.Autoscroll disrupted reading while messages arrived.A user-controlled go-to-bottom button.
  3. Every update refetches the whole thread.Whole threads were fetched redundantly.Lazy attachment loading with placeholders and retry, and less fetching.

method

Reproduce first, then ship in stages

  1. 1. reproducecolleagues used the chat the way customers did, planning a real visit in it; there were not enough users for a user study, so this took its place
  2. 2. find three causesone week
  3. 3. fix in a sprinttwo weeks, with two additional engineers
  4. 4. staged rollout internal → blue/green → all users

outcome

The spike, then the baseline

30-percentage-point spike fixes back to prior baseline
schematic, not data back to its prior baseline after the fixes, as reported by leadership

stack

  • TypeScript
  • Next.js
  • PostgreSQL
  • Prisma
  • S3

ownership

Who did what, and when

  1. diagnosis1 week
  2. fix sprint2 weeks
  3. staged rollout
  4. baseline restoredas reported
  • MeThe investigation and the described fixes
  • The CTOWorked close to, under a broad get-things-done remit
  • Two engineersThe additional frontend redesign and new backend endpoints
  • Churn measurementLeadership's figure; I did not inspect the counts

What shipped

Diagnosed in one week, fixed over a two-week sprint, rolled out in stages.

  • Leadership reported a 30-percentage-point churn spike returning to its prior baseline after the fixes.
Method and caveats

The churn figure comes from the CTO and manager; I did not inspect the counts, and it shows association, not isolated causality. Acceptance check was the basic absence of failures.

  • The 30-point churn spike and its return to baseline are leadership's report, not something I inspected; it shows association, not isolated causality.
  • Diagnosis in one week and a two-week fix sprint are my own account of the delivery.
  • The chat thread above is a simulation.