The crash that only happened while you were leaving

The best bugs only show up when nobody's looking. This one crashed the app the moment a user left the screen, right after they'd stopped caring about it.

It came in as a crash report that was easy to wave off. An IllegalArgumentException deep inside React Native's animation code, on Android, with a message that almost sounds bored:

java.lang.IllegalArgumentException: Mapped property node does not exist
    at com.facebook.react.animated.PropsAnimatedNode.updateView

It didn't reproduce on demand. It showed up in the wild, on some devices, some of the time, usually during screen changes. Real users kept hitting it and I couldn't trigger it once on my own machine. That pattern almost always means a race condition. Races are where "it works on my machine" goes to die.

What was actually happening

React Native's old animation system keeps a graph of nodes. A props node holds one child node per animated property. Every frame, it walks that list and writes each value onto the view. The line that crashed looked like this:

val node = requireNotNull(nodesManager.getNodeById(id)) {
  "Mapped property node does not exist"
}

requireNotNull is a promise. It says: this is never null, and if it is, something is badly broken, so crash. Here it could be null, for a completely ordinary reason.

When a component closes, say during a screen change, its animated child nodes get removed. But an update for the parent props node can already be running. So the order that crashes is this:

1. an update for the props node is queued
2. the component closes, so the child node is removed
3. the queued update runs, looks for the missing node, and throws

By the time step 3 runs the view is closing anyway. There's nothing worth writing for that property on that frame. The "error" the code was so sure about was just a teardown that hadn't finished yet.

The fix is small. That is the point.

Once you see the race, the fix writes itself. Don't assume the node is there. Check, and if it's already gone, skip it:

Two things told me this was the right skip and not a try/catch hiding a real bug. First, the same method already skipped work when the view itself was gone (connectedViewTag == -1). So "the thing I'm updating is gone, move on" was already how this code behaved. Second, iOS did exactly that. It walks its nodes and quietly skips a missing one. Android was the odd one out, turning an ordinary teardown into a hard crash.

A good fix makes the code agree with what the system was already telling you.

Shipping it to Meta

I opened the pull request against react/react-native and linked it to the old issue it closed. I wrote the test plan honestly. The crash depends on timing, so it doesn't happen every time. The trick is to make the race window bigger. Take the original repro, a screen with lots of animations running at once, and turn up "Animator duration scale" in Android's developer options. That slows the animations down and widens the window. The crash goes from "sometimes, on some phones" to "every time."

A Meta engineer imported it, it passed, and it landed. There's a particular thrill in three lines closing a bug that sat open for years. The work wasn't in the diff. It was in reading the race right.

What I took from it

Assumptions expire. requireNotNull wasn't wrong the day it was written. It assumed the node is always there during an update. Concurrency quietly made that false. A lot of "impossible" crashes are just an old assumption meeting new timing.

"Harmless" is something you have to prove. It would've been easy to swallow the error and move on. Skipping the node is safe here for reasons I can name: the guard the method already had, the way iOS behaved, and the order the steps run in. That's the difference between a fix and a mute button.