Understanding content of Blazor's render tree frames

[egil]

Hi @SteveSandersonMS et al,

I am tracking down a bug in bUnit, and want to validate some assumptions I have about a component's render tree frames.

The scenario: In Renderer.UpdateDisplayAsync, bUnit will get all render tree frames for a component and its child components to be able to build the markup for the component and its child components.

Getting all render tree frames for a component tree is done by calling a method like GetCurrentRenderTreeFramesDeep below (simplified for brevity) from UpdateDisplayAsync:

private void GetCurrentRenderTreeFramesDeep(int componentId)
{
  var frames = GetCurrentRenderTreeFrames(componentId);
  // store frames for later
  for (var i = 0; i < frames.Count; i++)
  {
    ref var frame = ref frames.Array[i];
    if (frame.FrameType == RenderTreeFrameType.Component)
    {
      GetCurrentRenderTreeFramesDeep(frame.ComponentId);
    }
  }
}

My assumption has been:

1. A child component that is disposed is removed from the render tree, e.g. calling GetCurrentRenderTreeFrames(componentId) does not return a frame.FrameType == RenderTreeFrameType.Component where frame.ComponentId references a component that was disposed in the current render cycle.
2. There are no cyclic references in the render tree frames, e.g. it should not be possible for a component A to have a frame pointing to component B which has a frame pointing to component A (directly or indirectly through other components).
3. A component instance/componentId can only be in the render tree once, i.e. be a child of one other component, or be a root component.

However, at least the second or third assumption seems to be wrong. A user has reported a stack overflow involving a method like GetCurrentRenderTreeFramesDeep above, indicating a cyclic reference between two or more components (using .NET 7.0.5).

Are my assumptions right? If not, please outline the cases where they are not.

[SteveSandersonMS]

A child component that is disposed is removed from the render tree

Disposal is async so it's best not to make assumptions about how quick it happens. However it doesn't sound like this is your main concern here.

There are no cyclic references in the render tree frames
A component instance/componentId can only be in the render tree once

That is true, at least with respect to parent-child relationships between components. Every component has zero or one parent, and the graph must be acyclic since children can only be added to parents that already exist and cannot move to a new parent later.

I don't know how you could be getting the infinite recursion issue. Possibilities could be:

• Something in your algorithm doesn't check FrameType before reading properties, and hence is getting undefined values
• Your code triggers rendering while walking the tree, causing the buffers to change under it and thereby reading off the end of buffer or similar

If you have a minimal repro I'm sure we could track it down.

[egil]

That's for confirming my assumptions. At least that narrows the problem space.

One of the changes we have made which seem to have fixed the issue is to check if the component we see get to in the render tree has been loaded before or if it was disposed according to the RenderBatch.

E.g., something like this:

private void GetCurrentRenderTreeFramesDeep(int componentId, Dictionary<int, ArrayRange<...>> dict, int[] disposed)
{
  var frames = GetCurrentRenderTreeFrames(componentId);
  dict.Add(componentId, frames);
  for (var i = 0; i < frames.Count; i++)
  {
    ref var frame = ref frames.Array[i];
    if (frame.FrameType == RenderTreeFrameType.Component && !dict.ContainsKey(frame.ComponentId) && !Array.Exists(disposed, x => x == frame.ComponentId))
    {
      GetCurrentRenderTreeFramesDeep(frame.ComponentId, dict, disposed);
    }
  }
}

I don't know how you could be getting the infinite recursion issue. Possibilities could be:

• Something in your algorithm doesn't check FrameType before reading properties, and hence is getting undefined values

That I am fairly certain we do, e.g. frametype == component.

• Your code triggers rendering while walking the tree, causing the buffers to change under it and thereby reading off the end of buffer or similar

This is a more likely reason. We are using a lock to prevent renders while we are accessing/walking the render tree. However, there may be cases we are missing.

However, my best guess is that there may be an ongoing UpdateDisplayAsync (where we read the render tree) when the renderer is disposed. I'll have to double-check that we stop any work after Renderer.IsDisposed is called.

If you have a minimal repro I'm sure we could track it down.

Unfortunately the user has not been able to share the production code so it's been hard to reproduce. I can see it is a use case that involves 1000s of components based on the log output that they have shared.

Ps. Writing from a beach in Spain, will follow up later.

[egil]

@SteveSandersonMS, I have continued my investigation and stumbled onto something (related): The RenderBatch.UpdatedComponents seems to have duplicated entries. I assume there is only one entry per component in any of the arrays in a RenderBatch.

As you can see in the screenshot below, the component with ID = 5 shows up twice, once with 5 edits and once with 0 edits. Do you know if this is expected?

The component's code looks like this:

<div>
    <EditForm Model='Entity'>
        <RadzenNumeric TValue='decimal?' @bind-Value='PaymentPercentFormatted'
                       Format='N6'
                       Min='0'
                       Max='100'>
        </RadzenNumeric>
    </EditForm>
</div>

@code {
    public decimal? PaymentPercentFormatted
    {
        get => Entity.PaymentPercent * 100m;
        set => Entity.PaymentPercent = value / 100m;
    }

    public CounterEntity Entity { get; set; } = new CounterEntity
        {
            Id = 100,
            PaymentPercent = .25m
        };

    public class CounterEntity
    {
        public long Id { get; set; }

        public decimal? PaymentPercent { get; set; }
    }
}

The RenderBatch is from the second render after dispatching the change event to the input field (Handling event {"Id":5,"Name":"HandlingEvent"} of type 'ChangeEventArgs').

Is this expected (.NET 7)?

[SteveSandersonMS]

Yes, it's always been the case. Components can render any number of times in a single batch. For example component A renders child B, which in turn does something that synchronously triggers the re-rendering of A. Then you'd get a batch with renders for A, B, A.

[egil]

Ahh I see, I always assumed that they would just be combined into a single entry in UpdatedComponents. We made some changes recently to deal with the stack overflow where that assumption led to unexpected behavior.

[SteveSandersonMS]

Ahh I see, I always assumed that they would just be combined into a single entry in UpdatedComponents.

That can't be done because the updates might not make sense in that order. Consider a case where A renders B, then B triggers a re-render of A, which then deletes B. We have a batch containing renders for A, B, A.

If somehow we tried to coalesce together the two entries for A, then we'd have A, B, but the render for A would contain an instruction to delete B even though it hasn't yet been created.

[egil]

Makes sense. We just changed our way of processing the RenderBatch and my wrong assumption wasn't affecting us before.

Can I assume duplicated entries (aka referenced to components) can also occur in DisposedComponentIDs?

[egil]

Can you please explain NamedEvent as well?