You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe the problem.
We're running into some challenges with rerendering loops. We have a rather complex use-case that we're building in Blazor SSR. Because the complexity, we've seen that some code paths could lead to infinite render loops because a StateHasChanged triggers itself via various ways (could be via other components)
We'd like a built-in detection or safeguard for infinite or excessive render loops in Blazor (particularly for Blazor Server)
In Blazor Server all connected clients can be affected by a single resource-usage spike on the server. Catching these problematic patterns early can save significant time in debugging and costly crashes in production environments. We've seen this happen multiple times over the months
Describe the solution you'd like
Proposal:
Introduce a fail-safe feature or diagnostic mode to detect repeated or continuous re-renders within a short time frame (similar to the infinite loop detection in frameworks like React).
Provide diagnostic logs or error messages indicating which component(s) triggered repeated renders.
Optionally, throttle or halt rendering until the problematic code path is resolved, to prevent server crash.
Additional context
Once we are running into a scenario where all server resources are being depleted by a render loop, we usually take a memory dump. Upon inspecting the memory dump we see objects like RenderTreeDiff and RenderTreeFrame. These lists can build up to multiple gigabytes memory
Example:
Problem Context:
In larger Blazor Server projects, it's relatively 'easy' for components to trigger each other's StateHasChanged(), causing repeated re-renders.
In certain cases, this can escalate into a render loop with no end. (Even when a Blazor circuit is closed)
The result is a spike in server resource usage—especially memory—that can consume all available resources and lead to an application crash or forced restart. This will also cause a spike in CPU usage as the garbage collector will have to work harder to clean up all created objects.
Currently, Blazor does not provide a straightforward way to detect or mitigate such loops.
A built-in detection mechanism or diagnostic warning could help developers quickly identify or prevent these scenarios, reducing downtime and production incidents.
The text was updated successfully, but these errors were encountered:
But I can imagine that there are better solutions to reach our goal of render loop logging/detection, which can be implemented in Blazor internally
Edit: Another solution is to track a small collection of DateTime values. Then, compare the first and for example the 100th DateTime. If the time apart is less than a second, there's a render loop detected. This might be better than starting a timer for every page.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
We're running into some challenges with rerendering loops. We have a rather complex use-case that we're building in Blazor SSR. Because the complexity, we've seen that some code paths could lead to infinite render loops because a StateHasChanged triggers itself via various ways (could be via other components)
We'd like a built-in detection or safeguard for infinite or excessive render loops in Blazor (particularly for Blazor Server)
In Blazor Server all connected clients can be affected by a single resource-usage spike on the server. Catching these problematic patterns early can save significant time in debugging and costly crashes in production environments. We've seen this happen multiple times over the months
Describe the solution you'd like
Proposal:
Additional context
Once we are running into a scenario where all server resources are being depleted by a render loop, we usually take a memory dump. Upon inspecting the memory dump we see objects like
RenderTreeDiff
andRenderTreeFrame
. These lists can build up to multiple gigabytes memoryExample:
Problem Context:
The text was updated successfully, but these errors were encountered: