The refund was approved — but the site kept saying "in progress"
A user's cancellation refund was approved and paid, yet their cabinet showed "in progress" forever. The bug lived between two systems that never talked to each other — here's how I found it, made the status update itself before the user's eyes, and prepared the flow for the statuses still to come.
We tested the new online policy cancellation end to end: a request was submitted, the accounting department approved it and sent the refund. Success — except the customer's cabinet still said "in progress". Not for a minute. Forever.
When a page talks about people's money, that's not a cosmetic bug. If we refund someone, our side must honestly say so — that was the whole goal of this week.
The mystery of the frozen status
The insurance core — where accounting works — knew the truth immediately. But the website keeps its own local copy of each request, written once at submission, and the claims page reads only that copy. The only thing that ever updated the copy was a "how is it going?" question to the core — asked only inside the cancellation wizard, a page the user has no reason to reopen.
I proved it with live data: at the same moment, the core answered "completed"
while our copy still said "in progress", untouched since day one. The truth
existed; the record of it didn't. Along the way I found the two sides even
spoke different dialects — one said success where the other expected
completed — so a fresh status would still have displayed wrong.
The fix: a page that quietly checks the truth
Together with my teammate who owns the backend, we chose the design where the claims page renders instantly from stored data, then quietly asks the core about each unfinished request in the background. As answers arrive, the status badge flips on screen — and each answer also heals the stored copy, so the database fixes itself just by people looking at their own claims.
Production guardrails: background checks run one at a time (our PHP worker pool is small), a failed check changes nothing on screen, finished requests are never re-checked, and a row that completes mid-view updates its badge but stays in its tab — nothing jumps out from under the user.
I validated it the honest way: reset the test request in the database, watched the network log — exactly one extra background request — and saw the badge flip to "Completed" about a second later. The next refresh was instantly correct: the database had healed itself on the first visit.
Two statuses today, four tomorrow
Right now the core only reports two states: under review and completed. The full lifecycle — including rejected and paid out — is still being built on the accounting (1C) side. Rather than pretend those don't exist, I built the status map ready for all four: today's unknown values are displayed safely instead of breaking anything, and the day accounting starts sending "rejected" or "paid", the cabinet needs only the new labels — not a redesign. Waiting on another team is normal; being ready for them is the job.
Meanwhile: cards for every product, and a bigger task ahead
Two more things happened today. First, our card payment (UzCard/Humo with SMS confirmation) had been limited to one product since launch — the gateway integration wasn't ready for the rest. It now is, so we're switching the card option on for every product, with a clean division of duties: the site offers the method, the backend decides which products accept it.
Second, I ran a deep performance audit of the whole platform — frontend and backend — and the results honestly worry me: multi-megabyte images, missing caches at every layer, a database doing far more work than it should. That's my next big undertaking, and the audit gave me what matters most: a ranked list, so the optimization starts with the changes that pay the most.
The lesson I keep relearning: when two systems disagree, the bug is rarely in either one — it lives in the silence between them.