DioxusLabs/dioxus · error

Failed to create new router after hot-patch!

Error message

Failed to create new router after hot-patch!

What it means

When the fullstack dev server receives a subsecond (hot-patch) build matching its build id, it applies the patch and rebuilds the application router through the hot_serve_callback from the launch config. If that callback returns Err, the server panics by design: it refuses to continue serving after a half-applied patch that could leave the app corrupted.

Source

Thrown at packages/fullstack-server/src/launch.rs:237

            // Handle just hot-patches for now.
            // We don't do RSX hot-reload since usually the client handles that once the page is loaded.
            //
            // todo(jon): I *believe* SSR is resilient to RSX changes, but we should verify that...
            Either::Right(DevserverMsg::HotReload(HotReloadMsg {
                jump_table: Some(table),
                for_build_id,
                ..
            })) if for_build_id == our_build_id => {
                // Apply the hot-reload patch to the dioxus devtools first
                unsafe { dioxus_devtools::subsecond::apply_patch(table).unwrap() };

                // Now recreate the router
                // We panic here because we don't want their app to continue in a maybe-corrupted state
                make_service = hot_serve_callback
                    .call(())
                    .await
                    .expect("Failed to create new router after hot-patch!")
                    .into_make_service();

                // Make sure to wipe out the renderer state so we don't have stale elements
                crate::document::reset_renderer();

                _ = shutdown_tx.send(());
            }

            // Explicitly don't handle RSX hot-reloads on the server
            // The client will handle that once the page is loaded. If we handled it here,
            _ => {}
        }
    }
}

fn block_on<T>(app_future: impl Future<Output = T>) {
    if let Ok(handle) = tokio::runtime::Handle::try_current() {
        handle.block_on(app_future);

View on GitHub (pinned to 393d190a80)

Solutions

1. Read the error printed with the panic — it is the real error from your serve callback; fix that root cause
2. Restart dx serve for a full rebuild to escape the half-patched state
3. Align toolchain: upgrade dioxus-cli and the dioxus workspace crates to the same release together
4. If it persists, disable hot-patching (use full-reload dev mode) or cargo clean and rebuild

When it happens

Trigger: Running dx serve on a fullstack app with hot-patching enabled; the callback that reconstructs the axum router returns Err — server function registration failures, router construction errors, or an incompatible subsecond patch applied to server code.

Common situations: Version skew between dioxus-cli (dx), dioxus-fullstack and subsecond crates; editing server-side code (server functions, router setup) in ways subsecond cannot cleanly patch; sockets/resources in a bad state after rapid successive edits.

Related errors

• Backend not ready after {max_wait:?}: {e}
• HTTP handshake failed: {e}
• Request failed: {e}
• Failed to parse index.html from public directory
• Lazy value is not initialized. Make sure to call `initialize

AI-assisted analysis of DioxusLabs/dioxus@393d190a80 (2026-08-16). Data as JSON: /api/errors/29c178ccd303622c. Report an issue: GitHub.