[Blazor] SetParametersAsync called multiple times with the same non-mutable parameters

[georgehemmings]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a Blazor component/page with a Route and Query String (SupplyParameterFromQuery) parameter. When both values change SetParametersAsync is called twice - the parameter/property values are identical on each call.

[Parameter]
public string Name { get; set; }

[Parameter]
[SupplyParameterFromQuery]
public int Count { get; set; }

Expected Behavior

I'd expect SetParametersAsync to be called once as the types of the parameters are non-mutable.
If both parameters are query parameters then SetParametersAsync is only called once.

Steps To Reproduce

Repro project: https://github.com/georgehemmings/BlazorDuplicateSetParams
The project is the a standard Blazor Server template with modifications to Counter.razor

Go to: https://localhost:7243/counter/A?Count=1000

Click "Counter A Add 1"
Then click "Counter B Add 1"

Observe "Current count" changes from 1000 to 1 as expected.
However note setParametersAsyncCalledCount jumps from1 to 3.
Alternatively place a break point on Line 56 of Counter.razor and observe that the parameters are the same for each execution.

Clicking either button repeated only increases setParametersAsyncCalledCount by 1. It's only when switching between the buttons that SetPamatersAsync is called twice.

Exceptions (if any)

No response

.NET Version

No response

Anything else?

.NET 9.0

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Router incorrectly calls SetParametersAsync multiple times #44781

[georgehemmings]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Router incorrectly calls SetParametersAsync multiple times #44781

It's similar and potentially the same underlying cause. However this is distinct in that the parameters are the same on both executions. Where the other issue is concerned with the the multiple executions with different parameters (old then new).

[javiercn]

@georgehemmings thanks for contacting us.

This is very likely a dupe of #44781.

I can't tell for sure what's going on, but it likely is a result of the query parameters being a Cascading value as opposed to a regular parameter.

The router subscribes to location changed events and so does the SupplyParameterFromQueryValueProvider. What likely happens is that they both signal the component independently (the router immediately schedules a render, and the query provider triggers a cascading value parameter update).

That sequence of events likely results on SetParametersAsync being up called twice.

With all that said, note that calling SetParametersAsync multiple times with the same values, while potentially wasteful is not incorrect. The framework choosing to compare parameters and skip calling SetParametersAsync is considered a performance optimization, not a correctness guarantee. We expect components to always be able to render when new parameters are passed in, whether different or equal.

[javiercn]

On second look though, I think there might be an issue with the QueryStringValueProvider.

At some point it seems to get behind the actual query state by 1

[georgehemmings]

Thanks for your prompt reply. I raised as the impact felt similar to this #54091 (comment)

I will track the previous values and check they've changed before performing IO.

[javiercn]

@georgehemmings this is what I did

    public override async Task SetParametersAsync(ParameterView parameters)
    {
        await base.SetParametersAsync(parameters);
        setParametersAsyncCalledCount++;
        captures.Add((Name, Count));
    }

[javiercn]

@georgehemmings I do suspect this has to do with the fact that multiple parameters are changing at the same time.

We'd have to debug the framework internals to learn more about the root cause. It might be a side effect of the change we did on the comment you mentioned, but the value on the URL is out of sync with the value on the component, which I would categorize as a bug.