Skip to content

Conversation

MackinnonBuck
Copy link
Member

@MackinnonBuck MackinnonBuck commented Jan 12, 2024

Allow null parameter values to be supplied to interactive components via enhanced page update

Backport of #53317

Fixes an issue where a NullRefrenceException would be thrown if an enhanced page update supplied a null parameter to an interactive root component.

Description

In .NET 8, SSR'd components can supply updated parameters to existing interactive root components. If one of those updated parameters is null, an exception currently gets thrown from within the framework. This causes the circuit to crash when using Server interactivity, and it would causes an error to be logged in the browser console when using WebAssembly interactivity.

This PR fixes the problem by treating null as a valid value for a serialized parameter that gets supplied to an interactive root component.

Fixes #52434

Customer Impact

Without this fix, customers may encounter the unfriendly exception and have a hard time figuring out the underlying cause. We have not yet seen customer reports of the issue, but it's possible that customers have this bug in their apps without knowing it, especially since it only occurs when supplying updated parameters to existing components (not when supplying the initial set of parameters).

One workaround would be to use a different value than null to specify an empty parameter value, but this may not be possible in cases where the parameter gets supplied by the framework (e.g., via route value), or if the interactive root component's implementation is not under the developer's control.

Regression?

  • Yes
  • No

Only applicable to new scenarios in .NET 8.

Risk

  • High
  • Medium
  • Low

The fix is straightforward and well-tested.

Verification

  • Manual (required)
  • Automated

Packaging changes reviewed?

  • Yes
  • No
  • N/A

@MackinnonBuck MackinnonBuck added Servicing-consider Shiproom approval is required for the issue area-blazor Includes: Blazor, Razor Components labels Jan 12, 2024
@MackinnonBuck MackinnonBuck requested a review from a team as a code owner January 12, 2024 23:56
@ghost
Copy link

ghost commented Jan 12, 2024

Hi @MackinnonBuck. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

@ghost ghost added this to the 8.0.x milestone Jan 12, 2024
@ghost
Copy link

ghost commented Jan 12, 2024

Hi @MackinnonBuck. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

@mkArtakMSFT mkArtakMSFT added Servicing-approved Shiproom has approved the issue and removed Servicing-consider Shiproom approval is required for the issue labels Jan 17, 2024
@ghost
Copy link

ghost commented Jan 17, 2024

Hi @MackinnonBuck. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

Copy link
Contributor

@mkArtakMSFT mkArtakMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved as this is a backport.

@mkArtakMSFT mkArtakMSFT merged commit e91e94d into release/8.0 Jan 17, 2024
@mkArtakMSFT mkArtakMSFT deleted the mbuck/backport-53317-to-8.0 branch January 17, 2024 21:25
@ghost ghost modified the milestones: 8.0.x, 8.0.2 Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components Servicing-approved Shiproom has approved the issue
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants