After upgrading a React Native app to 0.82 or later, why do red LogBox errors reading "Uncaught (in promise, id: …)" appear, and how do you handle them?

## The symptom after the upgrade A team upgrades its loyalty-card app to React Native 0.82 or later. Nothing in their code changed, but development builds now show **red LogBox errors** reading `Uncaught (in promise, id: 3): "..."`, sometimes followed by a warning `Promise rejection handled (id: 3)`. The error-reporting dashboard for the next build may show a jump in JavaScript errors too. ## What changed in React Native 0.82 The 0.82 release post lists it as a breaking change: **uncaught promise rejections now raise `console.error`**. The changelog entry is more precise — unhandled rejections are now handled by `ExceptionsManager.handleException` instead of being swallowed as LogBox warnings. The release post explains that a bug had previously swallowed them completely, and warns that pre-existing errors will surface after upgrading, including in JavaScript errors reported to your backend. In a development build on Hermes, React Native enables Hermes's promise rejection tracker with these options: | Event | What React Native does | |---|---| | a rejection has no handler | reports an error `Uncaught (in promise, id: N)` with the rejection's message as a **non-fatal** exception, so it appears as a red LogBox error | | a handler is attached later | logs a warning `Promise rejection handled (id: N)`, telling you the earlier message can be ignored | The rejection's original value is kept as the new error's `cause`. ## Why these were always bugs An unhandled rejection means some asynchronous work failed and **nobody reacted**: a points-balance request failed and the screen kept its spinner, a card-image download failed and the placeholder stayed forever. Before 0.82 those failures were invisible; the upgrade did not create them, it revealed them. Common sources in React Native code: 1. **Fire-and-forget calls in effects** — `useEffect(() => { refreshBalance(); }, [])` where `refreshBalance` is async and never caught. 2. **Async event handlers** — `onPress={async () => { await redeem(); }}` with no `try`/`catch`. 3. **Library calls that reject** — a storage read, a permission request or a native module call whose promise nobody awaits. 4. **Rethrowing in a `catch`** without a caller that handles it. ## How to handle them - **Treat each as a bug.** Find the call site from the stack and the message; the rejection's `cause` holds the original error. - **Handle the failure where it happens.** Add `try`/`catch` around awaited calls, or `.catch()` on promises you deliberately do not await, and put the UI into an error state rather than leaving a spinner. - **Do not add `LogBox.ignoreLogs([/Uncaught \(in promise/])`.** It hides every future failure of this class in development, and it does nothing about the reports your production error tracking now receives. - **Expect a production spike** in reported JavaScript errors after shipping the upgrade, and triage it rather than treating it as a regression in the upgrade itself. ```tsx import { useEffect, useState } from 'react'; export function useBalance(fetchBalance: () => Promise<number>) { const [balance, setBalance] = useState<number | null>(null); const [failed, setFailed] = useState(false); useEffect(() => { fetchBalance() .then(setBalance) .catch(() => setFailed(true)); }, [fetchBalance]); return { balance, failed }; } ``` ## Why it is a senior question It combines reading release notes, understanding that a change in error **reporting** is not a change in app **behaviour**, and resisting the easy fix of silencing LogBox. The candidate who says "the upgrade broke promises" or "just ignore them" has missed what the red boxes are for.