Error: "Could not find node with id "266" in commit tree"

[ldcc-juj]

PLEASE INCLUDE REPRO INSTRUCTIONS AND EXAMPLE CODE

I got this error when I click 'Ranked'.

---

Please do not remove the text below this line

DevTools version: 4.0.4-3c6a219

Call stack: at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:11:11441
at Map.forEach ()
at commitIndex (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:11:11387)
at e.getRankedChartData (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:11:11920)
at _i (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:56:277123)
at Ha (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:43:55890)
at Xl (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:43:98280)
at Hl (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:43:84255)
at Fl (chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:43:81285)
at chrome-extension://fmkadmapgofadopljbjfkapdkoienihi/build/main.js:43:25363

Component stack: in _i
in div
in div
in div
in Or
in Unknown
in n
in Unknown
in div
in div
in Ha
in le
in ve
in ko
in Ul

[bvaughn]

More detailed repro steps would be appreciated. What did you do up util you clicked "Ranked"?

[Apollinaire]

Same here. I got this problem today on this profiling: https://gist.github.com/Apollinaire/effeb23efae1d603e9e0b6a8e39132e5
First time i had the error it said id 273, then I refreshed the page, the profiling was still present so I downloaded it to see if just the profiling reproduces the error. It does, but now it says id 257.
Reproduction: I just opened the profiler, recorded, fiddled with my app, stopped the record, then looked at the commits. Everything was fine, until I clicked on the Ranked tab. I instantly saw the error message that got me here.
Version: React Developer Tools 4.2.1 (11/27/2019) Adds React debugging tools to the Chrome Developer Tools. Created from revision 3816ae7c3 on 11/27/2019.
Hope that helps

[bvaughn]

@Apollinaire Thank you for sharing the profile JSON and extra info! 🙇

[bvaughn]

Digging into the repro this morning.

Looks like the missing Fiber (257) is in the data, but according to the operations array, it doesn't get added until the second commit. However the profiler data for the commit references it in the first commit. Not accounting for that, there seem to be other Fibers that are also off by one like this.

Looking closer at the operations array, I see 5 commits even though there are only 3 commitData entries. Two of the operations entries stand out because of their small size:

// For more info see
// https://github.com/facebook/react/blob/master/packages/react-devtools/OVERVIEW.md
[
  1, // renderer id
  1, // root id
  0  // string table size
],

I think this might be the key to the problem. I think these commits are bailouts so the profiler is ignoring them. Except it's also indexing their operations arrays - so it's ending up throwing things off. If I manually adjust the profiler data to remove these two no-op entries, the data loads and parses without any errors.

To add more clarity, I think what is happening is that the backend realizes the commit was empty and so it does not record any profiler data for it:

react/packages/react-devtools-shared/src/backend/renderer.js

Line 1782 in b05cd61

if (isProfiling && isProfilingSupported && !didBailoutAtRoot) {

react/packages/react-devtools-shared/src/backend/renderer.js

Line 1826 in b05cd61

if (isProfiling && isProfilingSupported && !didBailoutAtRoot) {

But it does still flush the operations to the front end:

react/packages/react-devtools-shared/src/backend/renderer.js

Line 1843 in b05cd61

flushPendingEvents(root);

We have a check for this case which actually seems to cause this problem rather than prevent it:

react/packages/react-devtools-shared/src/backend/renderer.js

Lines 1024 to 1029 in b05cd61

	// If we're currently profiling, send an "operations" method even if there are no mutations to the tree.
	// The frontend needs this no-op info to know how to reconstruct the tree for each commit,
	// even if a particular commit didn't change the shape of the tree.
	if (!isProfiling) {
	return;
	}

I have a solid lead now on how to dig into this! 😄

[bvaughn]

The specific bailout paths I linked to above were added after this issue started happening (#17253) but I think the general idea of what's causing this bug is still correct.

In fact, the new test I added for #17253 demonstrates the bug path I mentioned above (so I'll need to fix that). This may account for why we're seeing more reports of this issue recently. The bug was clearly around before that change too though, so I'll need to find the other path.

The didBailoutAtRoot condition and the later check to see if anything was newly mounted or unmounted aren't really the same. (Both can happen in the same commit but not necessarily.) For example, just re-rendering the same tree at the root level will result in an operations "empty" array looking like the one above, but would not match the recently-added "bailout" check.

[bvaughn]

@Apollinaire I don't suppose you are able to repro this broken profile export? If so, is there any chance I could see the code that reproduces it? Might help me to track down exactly why it's happening.

[bvaughn]

FYI v4.4 (released today) should greatly improve this issue, but will not fix it entirely. I'm still working on it.

[bvaughn]

Hopefully fixed by #17771

[Apollinaire]

@bvaughn I was able to repro it a couple of times when I submitted my first comment here. I have not tried to do it again since I can see that you have (hopefully) found a solution.
And yes, the original code that was profiled is private.