Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Closed
  • Is something wrong?
#3,572 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, typescript
Domain
frontend

Research direction

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.

Written by the indexing model from the issue text.

Description

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));
run output
node --conditions=browser repro.mjs (2.0.0-rc.9 production) ["parent","child","grandchild"]
node --conditions=browser --conditions=development repro.mjs ["grandchild","child","parent"]
same two runs against the server builds (no browser condition) same split
solid-js 1.9.15, production build ["grandchild","child","parent"]
solid-js 1.9.15, development build ["grandchild","child","parent"]

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.

Dominant language
TypeScript
Stars
36.1k
Forks
1.1k
Avg merge
9h 56m
Merged PRs (30d)
268

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solidjs/solid

All issues in solidjs/solid

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.