Lock on the cleanNode function

[arvid220u]

Summary

It is possible for cleanNode to be called recursively. This PR adds a simple isCleaning lock to ensure that cleanNode isn't called on the same node twice.

Minimal example: https://playground.solidjs.com/anonymous/9f860e26-d0a3-476d-8b20-82ebff4763d7 (when you click "hide", you get a Cannot read properties of null error which comes from cleanNode being called twice on the same node).

I believe this error is most likely to happen when your entire app isn't in Solid, but you're instead mounting several Solid roots inside an existing application. We have global state controlling which Solid roots and components to show, and a syncState function that reads from the global state and disposes/creates Solid roots based on that. If component A has a Show that causes component B to be disposed, and component B has an onCleanup that calls the global syncState which disposes the entire Solid root that A is rendered in, then A will error in the cleanNode function.

I believe that this change should solve this problem, but I would love input on whether this change is reasonable at all, or whether it may have side effects that I haven't considered.

Thank you!

How did you test this change?

Would love advice on where you think it'd be best to add a test for this — didn't do it yet, because would first love input on whether this change makes sense.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4cff3e4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ryansolid]

I think it does. The only challenge is concurrency. That being said I don't think it changes the desire for this. Just it complicates things a bit.

[tmm1]

Was this resolved in a different way? The linked playground no longer throws an error.

[andrerocco]

@tmm1

Here is a snippet where a similar error occurs:

import { render } from "solid-js/web";
import { createMemo } from "solid-js";
import { MetaProvider, Title } from "@solidjs/meta";
import { Route, Router, useNavigate, useParams } from "@solidjs/router";

function RepoPage() {
  const navigate = useNavigate();
  const params = useParams<{ id?: string }>();
  const title = createMemo(() => params.id ?? "");

  return (
    <div>
      <Title>{title()}</Title>
      <button onClick={() => navigate("/")}>Back</button>
    </div>
  );
}

function HomePage() {
  const navigate = useNavigate();
  return <button onClick={() => navigate("/x")}>Go</button>;
}

function App() {
  return (
    <MetaProvider>
      <Router>
        <Route path="/:id" component={RepoPage} />
        <Route path="/" component={HomePage} />
      </Router>
    </MetaProvider>
  );
}

render(() => <App />, document.getElementById("root")!);

Versions:
"@solidjs/meta": "^0.29.4",
"@solidjs/router": "^0.16.1",
"solid-js": "^1.9.12",

The error is thrown when the Back button is clicked. The app crashes (freezes), and the following gets logged:

Crash log

dev.js:959 Uncaught (in promise) TypeError: Cannot read properties of null (reading '0')
    at cleanNode (dev.js:959:65)
    at cleanNode (dev.js:959:50)
    at cleanNode (dev.js:959:50)
    at cleanNode (dev.js:959:50)
    at cleanNode (dev.js:959:50)
    at cleanNode (dev.js:959:50)
    at updateComputation (dev.js:688:3)
    at runTop (dev.js:799:7)
    at runQueue (dev.js:870:42)
    at completeUpdates (dev.js:826:84)

An important detail is that removing createMemo from const title = createMemo(() => params.id ?? ""); will also prevent the error.
Observation: while createMemo may seem unnecessary in this snippet, it was more justifiable in the original code

The fix proposed in this PR does indeed stop the error from happening.

That said, the following change (made on top of signal.ts in main) also fixes it.

Alternative fix

diff --git a/packages/solid/src/reactive/signal.ts b/packages/solid/src/reactive/signal.ts
--- a/packages/solid/src/reactive/signal.ts
+++ b/packages/solid/src/reactive/signal.ts
@@ -1695,14 +1695,16 @@ function cleanNode(node: Owner) {

   }
 
   if ((node as Memo<any>).tOwned) {
-    for (i = (node as Memo<any>).tOwned!.length - 1; i >= 0; i--)
-      cleanNode((node as Memo<any>).tOwned![i]);
+    const tOwned = (node as Memo<any>).tOwned!;
     delete (node as Memo<any>).tOwned;
+    for (i = tOwned.length - 1; i >= 0; i--) cleanNode(tOwned[i]);
   }
   if (Transition && Transition.running && (node as Memo<any>).pure) {
     reset(node as Computation<any>, true);
   } else if (node.owned) {
-    for (i = node.owned.length - 1; i >= 0; i--) cleanNode(node.owned[i]);
+    const owned = node.owned;
+    node.owned = null;
+    for (i = owned.length - 1; i >= 0; i--) cleanNode(owned[i]);
     node.owned = null;
   }

From what I can tell, the issue is that cleanNode recurses through mutable fields (tOwned during transitions and owned otherwise), while those same fields can also be cleared by a re-entrant cleanup path. That makes it possible for an outer loop to still be reading from node.owned[i] after node.owned has already been set to null.

The changes proposed above avoids that by snapshotting the child list into a local variable and detaching it from the node before recursing, so the recursive cleanup no longer depends on a field that may be mutated during re-entry.

UPDATE

The scenario I outlined above was apparently being caused by @solidjs/meta's Title component being read during cleanup. The fix of version 0.29.5 stops the bug.

Even though the proposed fix is small and non intrusive, if it is true that “Solid’s cleanup code assumes cleanup functions don’t perform reactive reads that can re-run computations,” then I’m not sure it makes sense to guard against what may ultimately be a misuse case. The fix may even introduce silent leaks, I didn't end up testing against that, so I don't know -- would need an expert opinion on this.