"Loading events" hangs (fiber not defined)

[theprojectsomething]

I'm getting errors due to undefined fibers. Debugger is pointing specifically at:

react-render-tracker/src/data/process-events.ts

Lines 203 to 206 in a3794fe

	case "update":
	updateCount++;
	fiber = fiberById.get(event.fiberId) as MessageFiber;

Other cases seem to be solving this by first checking getFiberById.has(fiberId) and continuing if not. However, I'm guessing this would create knock-on effects downstream. Not to mention that the missing fiber is probably a symptom of an issue further upstream. Will investigate further with a local / unminified build and see what I can find.

Please let me know if there's any further detail I can provide.

[theprojectsomething]

After some (very) high-level debugging I was able to apply a band-aid solution to get rendering working on our unwieldy app, with the following steps:

1. Check for the existence of the fiber in process-events.ts > processEvents > case "update":

export function processEvents(
    [...]
    case "update":
        if (!fiberById.has(event.fiberId)) {
          continue;
        }
    [...]

2. Default to the closest fiber in fiber-maps.tsx > useFiberChildren

export const useFiberChildren = (
  fiberId: number,
  groupByParent = false,
  includeUnmounted = false
) => {
  const { selectTree } = useFiberMaps();
  const tree = selectTree(groupByParent, includeUnmounted);
  let leaf = tree.getOrCreate(fiberId);

  // fiber {0} invalid? find the next one that works
  if (!fiberId && leaf?.fiber == null && ) {
    for (const [activeFiberId, { fiber, firstChild }] of tree.nodes) {
      if (fiber && firstChild) {
        leaf = tree.getOrCreate(activeFiberId);
        break;
      }
    }
  }
  [...]

This solution obviously doesn't take into account the root cause. I'm also not aware of any knock-on effects at this time, though I'm sure they exist.

Am really appreciating the project. Keen to help find a solution that can make its way upstream. Any more insight / pointers in that regard would be much appreciated.

P.S. haven't provided a PR as not sure it would be useful in this case

[lahmatiy]

@theprojectsomething Please, try a new version 0.7.1 released today. Does problem persist?

Your proposition is fixing consequences. I believe, it should not be fixed that way. I did some refactoring in the last release, it might help. Otherwise, in your code some fiber type is used that is not covered by RRT properly. That's the most luckily a root cause. Just ignoring an event can lead to more errors.

[theprojectsomething]

Thanks @lahmatiy ... appreciate the quick response! Yes, the fix here is only working around consequences, though we're keen to dig further into it if you're able to provide any pointers. Is there a straightforward way to debug fiber types within the tree map / event processor?

As far as I know we're not doing anything radical in our environment. Currently running react 18.0.34. Could it potentially be a plugin or even custom elements?

Regards latest updates, the build we've based our testing off here (and in the fork) is the latest from the main branch, which included your updates from a couple of days ago. I've just rebased now to confirm, but yes the problem remains without the workaround in place.

I put up a placeholder PR #33 with our fix in place, but there is no intention to have that merged. Just as a discussion starter.

[theprojectsomething]

I should note that the useFiberChildren fix only applies to the root node (fiberId===0), so there would appear to be no other effected leafs / trees. Does the root node always start at index 0?

[lahmatiy]

@theprojectsomething Please try 0.7.3, it might work

[theprojectsomething]

Thanks @lahmatiy I've just tried it but unfortunately no luck with 0.7.3. The errors look similar, if not the same, as the previous builds (i.e. attempting to directly access properties of undefined fibers within the update case of processEvents).

I will try and find some time to debug the latest version (0.7.3) this week. And potentially to step through the whole data flow so I have a better mental model of what might be going wrong upstream, in our specific scenario.

If you're interested, we're attempting to implement the library on the (non-public) development version of abc.net.au/news. If you have a way to inject a script prior to page load (e.g. tampermonkey) then you should be able to see the errors we're seeing at that URL.

Thanks again!