fix: prevent endless recursion loading render tree frames#1132
Conversation
| // Add disposed components to the frames collection | ||
| // to avoid them being added into the dictionary later during a | ||
| // LoadRenderTreeFrames/GetOrLoadRenderTreeFrame call. | ||
| renderEvent.Frames.Add(id, default); |
There was a problem hiding this comment.
As we remove the component on line 290 - it would be also nice to understand if we run into an else case:
if (renderedComponents.TryGetValue(id, out var rc))
{
...
}
else
{
throw new UppsieException("Wuppsie, that should not happen!");
}Or we just look the stuff there.
There was a problem hiding this comment.
I don't expect much of a change if we hold a second list of disposed objects and one where we remove disposed objects.
There was a problem hiding this comment.
not sure I understand.
My assumption is that even though a component is disposed, it may still linger in the current render tree and be picked up when we walk through that.
Yes, we remove the component in line 290, but that is just our internal tracking of that component.
But yes, it would be interesting to see if disposed components are still lingering in the render tree.
There was a problem hiding this comment.
Duhhh - yeah that is on me. I missed something there. Anyway I checked the code a bit deeper.
Wouldn't be easier to do the following:
if (frame.FrameType == RenderTreeFrameType.Component && renderedComponents.Contains(frame.ComponentId))We don't need a new list for an information we already have.
There was a problem hiding this comment.
I want to publish a preview package based on this code to have @groogiam try out the preview locally since he cannot share the code with me so I can experiment locally myself.
If that works, Ill try to clean things up.
There was a problem hiding this comment.
Wouldn't be easier to do the following:
if (frame.FrameType == RenderTreeFrameType.Component && renderedComponents.Contains(frame.ComponentId))
Unfortunately not, since the renderedComponents collection only has the rendered components we have returned to the user, not all components.
2 participants
Look at the logs that @groogiam has shared with me, I see a bunch of renders happening after the TestRenderer has been disposed, i.e. LogRenderCycleActiveAfterDispose is being triggered.
However, that does not explain the stack overflow. Thus, the following code should prevent loading render tree frames from being loaded in an endless loop, perhaps because were are attempting load render tree frames for disposed components.
fixes #1064
PR meta checklist
mainbranch for codeor targeted at
stablebranch for documentation that is live on bunit.dev.Code PR specific checklist