Blazor SSR form post handling: integrate errors with ErrorBoundary

[SteveSandersonMS]

As of preview 4, the new form post mechanism will have an inconsistency in exception handling:

• If an exception occurs during initial rendering, it will trigger the normal ErrorBoundary mechanisms, and the response will be a 200
• If an exception occurs during the form submit event dispatch, it will bypass any ErrorBoundary, and the response will be a 500 because the exception flows up into the ASP.NET Core pipeline

We actually want the exception to flow up into the ASP.NET Core pipeline in both cases (leading to a 500 by default) as that's more helpful for SSR.

Suggested implementation

Hopefully we could remove the special-case logic in Renderer.cs that distinguishes these cases based on the quiesce flag (which really should be orthogonal to this anyway): https://github.com/dotnet/aspnetcore/pull/47716/files#diff-329ab76a7fca1f1325c9c8a21d79c9d7731b5a2163b81b7797a86291b53e0153R432-R436

Instead, we could change HandleExceptionViaErrorBoundary or similar to be virtual so that the default renderer uses ErrorBoundary in all cases (which is the appropriate thing to do for interactive rendering) and the EndpointHtmlRenderer would have its own different behavior of bypassing error boundaries in all cases.

We need to check we have E2E tests showing the expected behavior occurs:

• In interactive rendering for synchronous exceptions
• In interactive rendering for asynchronous exceptions
• In SSR for synchronous exceptions
• In SSR for asynchronous exceptions

The first two of these should be covered already by our existing E2E tests, but we should check. I don't know whether we have E2E tests for the SSR error cases.

Thanks for contacting us.

We're moving this issue to the .NET 8 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.