DEV Community: Siddharth Pandalai

CancellationException is not an assassin

Siddharth Pandalai — Sun, 02 Aug 2026 07:30:50 +0000

I cancelled a coroutine. It kept running for 8 more seconds. It just did not care.

This was a search screen. You type, it fires a network request. Type again, it cancels the old request and fires a new one. Standard stuff. Except the old request kept running, and every so often it finished last and painted stale results right over the fresh ones. I had called cancel. I had watched it run in the debugger. The job was "cancelled." And still it went on.

The culprit was one line I wrote myself.

Cancellation is a message, not a bullet

This is the part people miss about Kotlin coroutines. Cancelling one does not reach in and kill it. It cannot. The coroutine has to cooperate. So the machinery throws a CancellationException up through your suspend calls, and that exception is the message: we are done, unwind, release your resources, stop.

Your job is to let that message travel. Most cancellation bugs are really one bug: you stopped the message from traveling.

The line that ate the message

try {
    results = api.search(query)   // a suspend call
} catch (e: Exception) {
    log("search failed")
}

This looks careful. It looks like good defensive code. It is a trap.

CancellationException extends Exception. So when cancellation fires mid-request, this catch (e: Exception) grabs it, logs "search failed", and carries on as if a network error happened. The coroutine never unwinds. The framework thinks you handled something. The work continues.

You caught the messenger, logged that he looked upset, and locked him in a cell. The message he was carrying never got delivered.

Four ways to stop doing this

1. Catch what you actually expect. Ninety percent of the time you do not want Exception. You want the specific thing that can go wrong.

try {
    results = api.search(query)
} catch (e: IOException) {
    showOfflineState()
}

CancellationException is not an IOException, so it sails right past and does its job.

2. If you must catch broadly, rethrow cancellation first.

try {
    results = api.search(query)
} catch (e: CancellationException) {
    throw e                       // let the message through
} catch (e: Exception) {
    log("search failed")
}

3. Know that runCatching has the same trap. It is a lovely little helper and it catches CancellationException too.

val result = runCatching { api.search(query) }   // also swallows cancellation

If you use it inside a coroutine, check for cancellation and rethrow, or do not use it there.

4. For cleanup that must run even while cancelling, use NonCancellable. A naked catch is the wrong tool for "always close this".

try {
    stream.write(data)
} finally {
    withContext(NonCancellable) {
        stream.flushAndClose()    // runs even though the coroutine is cancelling
    }
}

Why the language made it this way

Structured concurrency is the reason. When a parent scope cancels, every child needs to wind down cleanly and report back up. That only works if cancellation propagates. If any link in the chain swallows the exception, the parent never learns the child stopped, and your careful tree of coroutines turns into orphans that run in the dark.

So CancellationException is not an error to be defended against. It is the one exception in the system that is doing exactly what you asked. It is the app shutting things down cleanly, on time, on request.

The takeaway

Cancellation is a conversation, not a kill switch. If you swallow the message, the work does not stop. It just stops telling you it is still running.

Do not shoot the messenger.

🌀 Iteration 2 of **The Loopdown. field notes from an engineer who writes.
Series: **The Coroutine Court* · Featuring: The Messenger*
📚 The full series: The Coroutine Court

Follow the loop → LinkedIn · dev.to · GitHub

Teaching a phone to disbelieve its own GPS

Siddharth Pandalai — Sun, 19 Jul 2026 19:25:38 +0000

The bug report came in on a Tuesday. One line:

"Your app says I hit 400 kmph. I was at a red light."

He wasn't lying. Neither was the app. The phone genuinely believed it, and that is the interesting part.

I work on mileage tracking. If you have ever had an app quietly log your drives for expenses or taxes, that is the category. Trip accuracy is not a feature of the product. It is the product. When we started, ours sat around 50 percent, and almost every missing point traced back to the same thing: the phone lying to us with total confidence.

Here is how we got it to 95, and the one idea underneath all of it.

GPS is a witness with a concussion

We treat GPS like a source of truth. Out in the world, where people actually drive, it behaves more like a witness who took a hard knock to the head. Confident. Cooperative. Frequently wrong.

Three places break it badly:

Tunnels. The receiver loses its view of the sky. Instead of admitting that, it keeps reporting the last position it had, sometimes for 30 to 40 seconds. Then you come out the other end, it reacquires, and it snaps to your real location in a single jump. Take that jump, divide by the tiny time it took, and you get a parked car doing 400 kmph.

Urban canyons. Signals bounce off glass towers before reaching you (multipath, if you want the word). The phone averages the reflections and places you a street or two over, very sure of itself.

Parking garages. Nothing, then noise, then nothing again.

None of these are edge cases. They are Tuesday. So the question stopped being "how do we get better GPS" and became "how do we stop believing bad GPS."

Fix 1: catch the liars

The cheapest win first. For any travel mode there is a physically possible envelope. A person walking does not teleport 200 meters in a second. A car does not accelerate like a missile. So before a reading touches the trip, check whether it implies something physics would not allow.

fun GpsFix.isImpossible(prev: GpsFix, mode: Mode): Boolean {
    val meters = haversine(prev, this)
    val seconds = (timestamp - prev.timestamp).coerceAtLeast(1)
    val speed = meters / seconds
    return speed > mode.maxPlausibleSpeed   // walking, cycling, driving each differ
}

If it is impossible, drop it. This one guard killed the most embarrassing errors on its own, including the 400 kmph report. It is not clever. It just refuses to be gaslit.

Fix 2: dead reckoning, so a gap is not a hole

Rejecting bad points leaves you with gaps, and a tunnel is a big one. If you freeze until GPS comes back, the trip gets a straight line cutting across three streets.

So when GPS drops out, stop waiting for it and estimate. Take the last good heading and speed, read the accelerometer, and carry the position forward yourself. Old sailors did this by feel, no stars, no landmarks, just direction and time and a good guess. It drifts, so you cannot lean on it for long. But a tunnel is short, and "roughly right for 40 seconds" beats "confidently wrong" or "a hole in the map."

fun deadReckon(last: Position, imu: Imu, dt: Float): Position {
    val speed = last.speed + imu.forwardAccel * dt
    val distance = speed * dt
    return last.movedBy(distance, heading = last.heading + imu.turnRate * dt)
}

The trick is knowing when to trust it and when to hand control back to GPS the moment GPS is worth trusting again.

Fix 3: fuse, do not just pick

Which brings us to the real fix. Most of the accuracy came from stopping the "believe whoever spoke last" habit and weighing every input by how much it deserves belief right now.

A clean, consistent GPS fix pulls the estimate hard toward itself. A jittery one barely moves it. The dead-reckoned guess fills the space between. Nobody gets a veto. Everybody gets a vote, weighted by confidence.

A Kalman filter is the textbook home for this, and if you reach for one, good. But the win is not the filter. The win is the mindset: hold several noisy opinions at once, and lean toward the one that looks trustworthy this second.

The unglamorous half

None of this matters if the tracker is dead. On Android, the moment the screen sleeps, the system starts looking for background work to kill, and aggressive OEM skins kill harder. We ran the pipeline in a foreground service with a small floating bubble, partly so the user could see it working, mostly so the OS would leave it alone. A tracker that gets killed is 0 percent accurate no matter how good the math is. I spent nearly as long on staying alive as on the algorithm.

What actually took us from 50 to 95

Not one silver bullet. Spike detection removed the garbage. Dead reckoning covered the gaps. Fusion made the whole thing coherent. Staying alive made it real. Each one bought a chunk, and they compounded.

Steal this

Treat every external input as a witness who might be concussed, not a source of truth.
Give physics a veto. The cheapest correctness check is "could this even happen."
When a signal drops, degrade to a rough estimate instead of freezing or guessing wildly.
Weight inputs by live confidence, not recency.
Keep the thing alive first. Perfect logic in a killed process is worth nothing.

The one line I kept after all of it: good systems are not the ones with perfect inputs, because nobody gets perfect inputs. Good systems assume their inputs will lie, and plan for the day they do.

Trust, but verify. Especially your own sensors.

🌀 Iteration 1 of **The Loopdown. field notes from an engineer who writes.
Series: **Sensors Who Lie* · Featuring: The Concussed Witness*
📚 The full series: Sensors Who Lie

Follow the loop → LinkedIn · dev.to · GitHub