[2.0 rc.9] Production build runs component onCleanup callbacks parent-before-child (dev, observe and 1.x run child-first)

Start with runDisposal in packages/signals/src/core/owner.ts and the reverse-order cleanup test in packages/signals/tests/onCleanup.test.ts. Compare that behavior with production createComponent in packages/solid/src/client/component.ts and the development path in packages/solid/src/client/core.ts. Done means nested component cleanups run child-before-parent in production and the relevant tests pass.

Describe the bug

In the production build, onCleanup callbacks registered in component bodies run parent before child. The development and observe builds run child before parent, and so did every build of 1.x. The change only shows up in production, so nothing catches it during development.

import { createRoot, createComponent, onCleanup, DEV } from "solid-js";

const log = [];
const Grandchild = () => { onCleanup(() => log.push("grandchild")); return null; };
const Child = () => { onCleanup(() => log.push("child")); return createComponent(Grandchild, {}); };
const Parent = () => { onCleanup(() => log.push("parent")); return createComponent(Child, {}); };

const dispose = createRoot(d => { createComponent(Parent, {}); return d; });
dispose();
console.log((DEV ? "dev " : "prod") + " build:", JSON.stringify(log));

The consequence in an app is a parent that tears down a resource its children are still attached to:

const Series = (p) => { onCleanup(() => p.chart.removeSeries()); return <i>series</i>; };
const Chart = () => {
  const chart = makeChart();                 // any library object: chart, map, editor, socket
  onCleanup(() => chart.destroy());
  return <section><Series chart={chart} /></section>;
};

<Show when={open()} fallback={<u>closed</u>}><Chart /></Show>

Development: setOpen(false) logs removeSeries, then destroy. Production: destroy runs first, removeSeries() throws on the destroyed chart, and after that throw nothing on the page updates again — the <Show> never switches to closed, and unrelated buttons stop working. The same page in the development build keeps working.

Your Example Website or App

The script above runs against the built packages with plain node; the JSX example is what it looks like in a page.

Steps to Reproduce the Bug or Issue

1. Save the first snippet as repro.mjs next to a built checkout (or any project with [email protected] installed).
2. Run node --conditions=browser repro.mjs and node --conditions=browser --conditions=development repro.mjs.
3. Compare the printed order.

For the page version, mount the Chart/Series tree under a <Show> in a production build, toggle the <Show> off, and click anything else on the page.

Expected behavior

Children clean up before their parents in every build, as they did in 1.x, and as the development build still does. The signals core tests this contract for nested owners (packages/signals/tests/onCleanup.test.ts, "should clean up in reverse order").

Platform

• solid-js 2.0.0-rc.9 (next @ 37fd1e67), production vs development builds
• Node 24.21, macOS arm64; solid-js 1.9.15 used for the comparison rows

Additional context

Two things combine:

• The production createComponent is untrack(() => Comp(props)) with no owner of its own (packages/solid/src/client/component.ts:85), while the development and observe builds run every component inside createRoot(…, { transparent: true }) (observedComponent, packages/solid/src/client/core.ts:209-241). So in production a parent's and its children's cleanups all land on the same enclosing computation's disposal list, in registration order: parent first, because the parent's body runs before it creates the child.
• runDisposal walks that list forwards (packages/signals/src/core/owner.ts:168-183).

1.x also had no owner per component in production (the open #1561 is about that dev/prod split), but its cleanNode ran a node's cleanups in reverse (for (i = node.cleanups.length - 1; i >= 0; i--) in solid-js 1.9.15), so the order came out child-first anyway. 2.0 replaced that with a forward walk, which is what turns the old inconsistency into wrong behaviour.

The smallest change that restores the 1.x order is to walk _disposal in reverse in runDisposal. Giving production components an owner, as the development build does, would also fix it and would make getOwner() / isDisposed(owner) in a component body mean the same thing in both builds (today the production owner is the enclosing computation, shared by sibling components, so the bail-out pattern in isDisposed's own docstring never fires after a component unmounts).

A second effect worth knowing about while fixing this: once a cleanup throws during a flush, schedule() (packages/signals/src/core/scheduler.ts:404-412) is left latched, so no further microtask flush is ever queued and the page is dead until something calls flush() explicitly. That is why the page example stops responding rather than just logging an error.