A cancelled policy that still said "Active"

Cancelling an insurance policy is already an uncomfortable thing to do. Doing it, getting a confirmation, and then seeing the policy still sitting in your account marked "Active" is worse — it makes you wonder whether anything happened at all, or whether you're still being charged.

That's the bug I was handed. Fixing it turned out to be less about code and more about deciding whose word to trust.

Chasing where the lie came from

The policy list is drawn from the national insurance registry — the shared record of every policy in the country. Our site simply repeated whatever it said about each policy.

So I checked every cancellation ever submitted through the site against what the registry says today. Six requests, and the answers didn't agree with each other at all:

• One had been fully completed thirteen days earlier — and the registry still reported that policy as issued and valid.
• Two others were still under review by the insurer, yet the registry had already written them off.
• One had been refused outright, which is the one case where "still active" was correct.

The conclusion was uncomfortable but clear: the registry is not a reliable record of whether someone cancelled. It updates for some products, at some stage, and not for others.

Deciding whose word to trust

We have something better. Every cancellation submitted through the site is stored by us, along with the stage it has reached inside the insurer's own system.

So the rule became simple: the registry still decides whether a policy was issued or written off, but on the question "did this person cancel it?", our own record wins. That check now happens on the server, as the policy list is being built, so every screen that shows a policy — the list, the dashboard, the cancellation form — gets the corrected answer without having to know why.

One deliberate restraint: only a completed cancellation changes the status. If a request is still being reviewed, the policy keeps reading as active — because it genuinely still is. Saying otherwise would just be a different lie.

Telling the office the moment someone cancels

The second half was the opposite problem: a request arriving and nobody knowing.

A cancellation involves money going back to a person, so it needs a human. Now, the instant one is submitted, the team's Telegram group receives it — the product, the policy, the request number, the refund amount, whether a document was attached, who the customer is and why they're cancelling.

Four rules shaped that message more than the message itself:

1. Never before it's real. It's sent only after the insurer has accepted the request, so the group can't be told about something that failed.
2. Never break the thing it reports on. If Telegram is down, the cancellation still succeeds. The customer's request must never fail because a notification did.
3. Never make anyone wait. The call has a hard time limit, so a slow messenger can't hang the submit button.
4. Never repeat itself. Only a genuinely new request notifies, so a retry doesn't spam the team.

The failure that would have been invisible

Then I found a flaw in my own work. If Telegram refused the message — the bot not added to the group, or a wrong group — we sent it, got turned down, and recorded nothing. The cancellation would look perfect and the team would simply never hear about it.

That's the worst kind of bug: one with no symptoms. Now a refusal is written down with the reason the messenger gave, so it takes seconds to explain instead of an afternoon.

Why I'm happy with it

Both halves come down to the same idea. A system should say what it actually knows — not repeat a stale answer from somewhere else, and not stay quiet when something goes wrong.

The person cancelling now sees the truth about their own policy, and the people who have to act on it hear about it in seconds rather than whenever someone next checks a list.