Bug tracking for Remix — session replay, console + HAR (2026)

A Remix bug rarely lives on one side of the wire. The loader runs on the server, the action's revalidation runs back on the client, and the ErrorBoundary renders on whichever side actually threw — so the failing data shape and the rendered fallback end up on different halves of the request. That split is why a screenshot is nearly useless here: it shows the client-side fallback while the real cause sits in a server loader you cannot see from the DOM.

Remix also hides its own errors on purpose. In production the framework sanitizes any server throw before it reaches the browser: the message becomes "Unexpected Server Error" and the stack is undefined, so no internals leak. The detail you need survives only in the network response and in what the user did to trigger the throw. To debug a Remix loader/action failure you want three artifacts together — the rrweb DOM replay, the console (where hydration warnings name the mismatched node), and the full network HAR (where the thrown Response's real status code lives). BugMojo captures all three from one on-demand session.

Framework-specific failure modes engineers actually ship through. Each is hard to spot in a screenshot and obvious in a session replay.

Real Remix bug patterns — the symptom you will see in a report and the fix that actually works.

Hydration mismatch from a non-deterministic value

Symptom: Console warning that the server HTML did not match the client render; text flickers or a node swaps on first paint. Common triggers are a Date, locale-dependent formatting, a random id, or a browser extension mutating the DOM.

Fix: Remix's own guidance is that this is not a Remix bug but how React SSR works. The durable fix is to render the value only after hydration behind an isHydrated flag (the useHydrated hook from remix-utils) rather than reaching for suppressHydrationWarning, which only silences one node and hides the symptom. A captured console plus DOM replay shows the exact node that flickered and the warning that named it.

Action throws but the form looks like it saved

Symptom: User submits a form, the page shows no error, but nothing was persisted. The validation message your ErrorBoundary should display never appears.

Fix: An action that returns an error object (or resolves 200 with an error payload) instead of throwing a Response will not trigger the ErrorBoundary. Either throw a Response with the right status so isRouteErrorResponse() can branch on it, or surface the returned error in the component via useActionData. The captured HAR shows the POST to the action and its real status code, so you can tell whether the action threw, returned, or quietly resolved.

Deferred data streams everything at once or never finishes

Symptom: Either the page blocks until all data is ready (no streaming at all), or a skeleton spins forever for a deferred section.

Fix: Loading everything at once usually means you awaited the promise before passing it to defer; return the unawaited Promise so Remix can stream it by injecting script tags as it resolves. A skeleton that spins forever means the streamed promise never resolved or rejected inside its Await boundary. The network HAR distinguishes the two at a glance: it shows whether the streamed chunk arrived and which one stalled.

The honest comparison — where BugMojo wins, and where another tool might serve you better.