Open MackinnonBuck opened 1 year ago
"only".
This is well-known and no different than the existing limitations on Blazor Server. I acknowledge this is a problem, but it is not unique to Blazor. The solution here is the same, increase the signal R message size.
In the future we might consider breaking up the payload into multiple messages so that we avoid this limit altogether, which would be the appropriate solution for all our cases.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Discussed with the team that there is no point in having the message size limitation in Blazor. Blazor should chunk messages it generates internally to work well with the SignalR message size limitation and later deconstruct the full message when received on the other end.
Discussed with the team that there is no point in having the message size limitation in Blazor. Blazor should chunk messages it generates internally to work well with the SignalR message size limitation and later deconstruct the full message when received on the other end.
To clarify, we only mean that for data previously generated on the server to represent the list root component operations. The server can trust itself not to DoS itself when producing this data. For example, it can choose not to emit the initial data in the first place if it would be too large.
We do not think that arbitrary messages (which may contain arbitrary end user data) should be allowed to bypass the SignalR message size limit.
If a Blazor endpoint renders too many interactive server root components on the page at once, the message that contains each root component marker may exceed the default SignalR message size limit. This causes the app to stop working.
I was able to hit this limit in my testing with only ~28 root components.