Error boundary behavior during SSR hydration mismatches and cleanup of pending async promises

Short answer

Yes, componentDidCatch fires for hydration mismatches — a mismatch throws during the client render pass, and that error bubbles to the nearest error boundary like any other render error. No, StencilJS does not automatically abort pending promises when the boundary removes the component. Fetches, timers, and subscriptions started in componentDidLoad keep running unless you cancel them yourself in componentWillUnload.

Hydration mismatches and componentDidCatch

During hydration, the client re-renders the server-generated markup and compares it. When the output doesn't match, Stencil throws during the render/lifecycle phase, and errors raised there propagate to the closest ancestor that implements componentDidCatch(error, componentStack). The componentStack argument lists the Stencil component hierarchy at the failure point and is generally useful for identifying the offending component.

Two caveats, which I flag as needing verification against your exact Stencil version:

• Older Stencil releases have inconsistent componentStack output for hydration-time errors; the stack may be truncated if the mismatch happens very early in hydration.
• If the error boundary itself throws while rendering its fallback, the original mismatch error can be swallowed. Keep fallback rendering trivial.

Async cleanup is your responsibility

When an error boundary unmounts a component, the DOM node is removed and componentWillUnload runs — but nothing reaches into your in-flight work. A fetch started in componentDidLoad will still resolve, and its continuation will run against a detached component. The same applies to setTimeout/setInterval callbacks, which can hold references to the removed instance and leak memory.

The established pattern is an AbortController stored on the instance:

private controller = new AbortController();

async componentDidLoad() {
  const res = await fetch('/api/data', { signal: this.controller.signal });
  // ...
}

componentWillUnload() {
  this.controller.abort();
  clearTimeout(this.timer);
}

Note the boundary case in your question: componentDidCatch only catches errors thrown synchronously in render/lifecycle methods or in promises awaited within them. A rejection in a fire-and-forget promise (e.g., a .then() chain never awaited by a lifecycle method) will not reach the boundary — it goes to the global unhandledrejection handler. So an error boundary is not a substitute for per-request error handling.

How to verify this in your app

1. Wrap a child in an error boundary and force a hydration mismatch (e.g., render Date.now() so server and client output differ). Confirm componentDidCatch logs the error and inspect the componentStack content.
2. In the child, start a fetch with an AbortController, trigger the boundary, and watch the network panel: without abort() in componentWillUnload the request completes; with it, the request shows as cancelled.
3. Add a setTimeout that logs after unmount to confirm whether dangling callbacks fire — then clear it in componentWillUnload.

If you can share your Stencil version, the componentStack fidelity for hydration errors is the one behavior worth confirming against that release's changelog, since it has changed over time.