Add overrideWithFunction to ArgProvider for dynamic test overrides

[Copilot]

• Explore codebase and understand provider architecture
• Remove @immutable annotation from ArgProvider
• Add nullable _overrideFn field to ArgProvider
• Add overrideWithFunction method to ArgProvider
• Modify _generateIntermediateProvider to use _overrideFn ?? _createValue
• Add tests for overrideWithFunction (basic override, arg forwarding)
• Remove resetOverride method and its test per review feedback
• Bump version to 2.1.0 and update CHANGELOG.md

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Allow dynamic override of arg provider in testing</issue_title>
<issue_description>In testing, we may want to utilize the existing arg that is used inside of a widget when testing with mocks/overridden providers.

Is there some way/something we can introduce to pass the argument being created with so that when the provider is created, we can override with a different implementation function?

For example, using the number provider:

const numberProvider = Provider.withArgument((context, arg) => arg * 2);

...

testWidgets(..., (...) {
    ...
    ProviderScopeOverride(
          overrides:[numberProvider.overrideWithValue((arg) => arg * 4)]
          child: ...
    );

// Output with numberProvider(1) would be 4, not 2
});

Part of what we are testing could be that the argument provided to it is correct and produces a specific output</issue_description>

<agent_instructions>It would be ideal to have numberProvider.overrideWithFunction where a function that takes an argument A and returns T is returned.
Ideally, the overriden function is stored in the numberProvider itself, no need to put an override on top because it would make harder to access the arg passed to the original provider (not-overriden).
In this way, any A argument passed in non-overrides, can be safely passed to that overriden function when creating the real provider instance. Additionally, in this way no map updates are necessary in the core logic (no need to have an ArgProviderOverride in this scenario)

Don't worry if ArgProvider is no longer immutable, it is not really immutable given that _lazy is computed in the constructor, in fact const is missing in the class. You can safely remove that useless annotation.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@manuel-plavsic Can you explain to us what is your main goal with this? Can you give us a concrete example? You don't have to be very detailed. Like, would you like to have custom logic for specific use cases, e.g., login in tests does not actually call the main backend API for user authentication; instead, it uses an alternative backend API or you work with some hardcoded data? @manuel-plavsic I am very busy until March 20, so I will just give you a workaround for now, but I will come back to you later. Maybe @nank1ro finds time sooner than that to properly answer you.

You could make the argument a tuple, where the first tuple element is the "actual argument" and the second one is an enum (with two variants A and B). In the body of the provider, you then handle both variants A and B. When you insert the provider in the widget tree, you give an instance of variant A in the tuple. In the override, the argument is a tuple with variant B.

When you do injection, you mainly rely on the first element: numberProvider.of(context).value.$1. But you could also rely on the enum variant $2 (e.g., if you want to handle the logic of a different provider in multiple ways based on numberProvider's variant).

Hope this helps for the moment.</comment_new>

• Fixes Allow dynamic override of arg provider in testing #35

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

Provider Benchmark Results

Date: 2026-03-02 10:45:30 UTC

Results

Benchmark	Time (ms)
Create 100 simple eager providers	220
Create 100 simple lazy providers	12
Create 50 providers with dependencies	10
Retrieve 100 lazy provider values	1
Create 100 ArgProviders	10
Access 100 providers in nested scopes	10
Complex dependency chain (30 providers)	8
Mixed lazy and eager (100 total)	9
ArgProviders with dependencies (50)	9
Large scale (500 providers)	8
Deep dependency chain (100 levels)	7
Wide dependency tree (100 dependents)	8
Multiple nested scopes (5 levels)	9

[nank1ro]

@copilot remove resetOverride, it is not needed at all.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

@@            Coverage Diff            @@
##              main       #36   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines          288       288           
=========================================
  Hits           288       288           

Files with missing lines	Coverage Δ
...co/lib/src/models/providers/provider_argument.dart	100.00% <100.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

@copilot remove resetOverride, it is not needed at all.

Done — resetOverride has been removed from ArgProvider and its test in 47c075a.

[nank1ro]

@copilot bump the version in pubspec.yaml and update the CHANGELOG.md accordingly

[Copilot]

@copilot bump the version in pubspec.yaml and update the CHANGELOG.md accordingly

Done in 2b53dc4 — bumped version to 2.1.0 and added the entry to CHANGELOG.md.

[manuel-plavsic]

@nank1ro I think we need to have version 2.1.0 instead of 1.0.0 in https://disco.mariuti.com/installing/.

Also, do we have to add disco_lint under the dev dependencies in the pubspec.yaml?

[nank1ro]

@manuel-plavsic

Also, do we have to add disco_lint under the dev dependencies in the pubspec.yaml?

No, disco_lint needs to be present only in the analysis_options.yaml, because it's a linter plugin, not a dev dependency

[cloudflare-workers-and-pages]

Deploying flutter-disco with    Cloudflare Pages

Latest commit:	0daf85a
Status:	✅  Deploy successful!
Preview URL:	https://42f2ff4b.flutter-disco.pages.dev
Branch Preview URL:	https://copilot-allow-dynamic-overri.flutter-disco.pages.dev

View logs

[manuel-plavsic]

Pretty sure this implementation is not adequate. You probably want the provider to stay immutable. It should be more similar to:

  @visibleForTesting
  ArgProviderOverride<T, A> overrideWithValue(T value) =>
      ArgProviderOverride._(this, value, debugName: debugName);

and ArgProviderOverride should take one more parameter for the callback

[nank1ro]

Pretty sure this implementation is not adequate. You probably want the provider to stay immutable. It should be more similar to:

  @visibleForTesting
  ArgProviderOverride<T, A> overrideWithValue(T value) =>
      ArgProviderOverride._(this, value, debugName: debugName);

and ArgProviderOverride should take one more parameter for the callback

I intentionally said to copilot to do it in this way for two reasons:

1. Providers are not immutable (the annotation is there but this is a mistake). _lazy is computed and can't work if the class is const.
2. there is a comment written by you that says ! NB: do not make the constructorconst, since that would give the same hash code to different instances of Providerwith the same generic type.

If we use an ArgProviderOverride class, we make the logic more complex, because the override is inherited first, but the original descendant provider must be found to detect the arg passed to it (which is expensive and pretty complex in an unnecessary way).

PS: What I'm saying here is because I've already tried locally with an Agent to do what you've proposed. This was my first idea but it comes with a lot of complexity and many code changes needed

[manuel-plavsic]

1. Lazy is actually immutable: it is a runtime constant (final _lazy). The non-final constructor argument bool? lazy does not change the fact that _lazy itself is immutable. Also, so far the overrides automatically make stuff non-lazy, but that could be changed by adding a lazy argument to:

   @visibleForTesting
   ArgProviderOverride<T, A> overrideWithValue(T value) =>
       ArgProviderOverride._(this, value, debugName: debugName);
   

2. const means compile-time constant. Immutable does not imply compile-time constant, it can also mean runtime constant. Indeed, the constructor should not be const because of that comment.

Remember that providers and argument providers are just identifiers. A matching Provider is created behind the scenes to manage argument providers. In the past we experienced bugs and inconsistencies in our WIP feature branches when we tried to make the constructor no longer immutable and set the state directly inside the Provider or ArgProvider (I don't remember the details, but it was something major). Unfortunately, the code as it is in the PR now will probably lead to bugs.

Probable kind of bug (I did not test it, so I might be wrong):

// Note: numberProvider is ((arg) => arg * 2) and lazy
testWidgets(..., (...) {
    ProviderScope(
          providers: [numberProvider(2)]
          child: ...
             List [
                // somehow this is run first
                ProviderScopeOverride(
                      overrides:[numberProvider.overrideWithFunction((arg) => arg * 4)]
                      child: ...
                ),
                // ensure that the following is run second, after the override. Maybe some lazy screen or something like that.
                OtherWidget(inject numberProvider here...)
           ]       
    )
});

Problem: Inside OtherWidget, numberProvider will have ((arg) => arg * 4) instead of ((arg) => arg * 2), because the _overrideFn was set at the identifier level. The actual internal Provider was not created when you specified numberProvider(2); instead, since it is lazy, the internal Provider was created when you tried to inject the identifier provider for the first time following the override (where I wrote inject numberProvider here...).

For the same reason, also this kind of structure probably won't work.

// Note: numberProvider is ((arg) => arg * 2) and it can be either lazy or strict
testWidgets(..., (...) {
     List [
        // somehow this is run first
        ProviderScopeOverride(
              overrides:[numberProvider.overrideWithFunction((arg) => arg * 4)]
              child: ...
        ),
        // ensure that the following is run second, after the override. Maybe some lazy screen or something like that.
        ProviderScope(
            providers: [numberProvider(2)]
            child: OtherWidget(inject numberProvider here...) // value will be 8 instead of 4
        )
   ]       
});

Can you add such tests, so we can test my hypothesis?

[manuel-plavsic]

Let's not rush this PR. I have much more important priorities until the 20th of March. I will review it after that date. You can continue working on this and, once more or less ready, offer a way to test this branch in #35.
If you are busy, you can also leave it like this otherwise; I will continue working on it following the mentioned date.

[nank1ro]

@copilot given the comment made by manuel

Lazy is actually immutable: it is a runtime constant (final _lazy). The non-final constructor argument bool? lazy does not change the fact that _lazy itself is immutable. Also, so far the overrides automatically make stuff non-lazy, but that could be changed by adding a lazy argument to:

@visibleForTesting
ArgProviderOverride<T, A> overrideWithValue(T value) =>
    ArgProviderOverride._(this, value, debugName: debugName);
const means compile-time constant. Immutable does not imply compile-time constant, it can also mean runtime constant. Indeed, the constructor should not be const because of that comment.

Remember that providers and argument providers are just identifiers. A matching Provider is created behind the scenes to manage argument providers. In the past we experienced bugs and inconsistencies in our WIP feature branches when we tried to make the constructor no longer immutable and set the state directly inside the Provider or ArgProvider (I don't remember the details, but it was something major). Unfortunately, the code as it is in the PR now will probably lead to bugs.

Probable kind of bug (I did not test it, so I might be wrong):

// Note: numberProvider is ((arg) => arg * 2) and lazy
testWidgets(..., (...) {
    ProviderScope(
          providers: [numberProvider(2)]
          child: ...
             List [
                // somehow this is run first
                ProviderScopeOverride(
                      overrides:[numberProvider.overrideWithValue((arg) => arg * 4)]
                      child: ...
                ),
                // ensure that the following is run second, after the override. Maybe some lazy screen or something like that.
                OtherWidget(inject numberProvider here...)
           ]       
    )
});
Problem: Inside OtherWidget, numberProvider will have ((arg) => arg * 4) instead of ((arg) => arg * 2), because the _overrideFn was set at the identifier level. The actual internal Provider was not created when you specified numberProvider(2); instead, since it is lazy, the internal Provider was created when you tried to inject the identifier provider for the first time following the override (where I wrote inject numberProvider here...).

For the same reason, also this kind of structure probably won't work.

// Note: numberProvider is ((arg) => arg * 2) and it can be either lazy or strict
testWidgets(..., (...) {
     List [
        // somehow this is run first
        ProviderScopeOverride(
              overrides:[numberProvider.overrideWithValue((arg) => arg * 4)]
              child: ...
        ),
        // ensure that the following is run second, after the override. Maybe some lazy screen or something like that.
        ProviderScope(
            providers: [numberProvider(2)]
            child: OtherWidget(inject numberProvider here...) // value will be 8 instead of 4
        )
   ]       
});
Can you add such tests, so we can test my hypothesis?

Can you add the required tests he mentioned?

[Copilot]

@copilot given the comment made by manuel

...

Your comment appears to be cut off after @visibleForTesting ArgProviderOverride — could you share the full intended API signature? Based on the discussion, I understand the direction is to keep ArgProvider immutable and have overrideWithFunction return an ArgProviderOverride (instead of mutating the provider), but I'd like to confirm the exact shape you have in mind before making changes.

[nank1ro]

1. Lazy is actually immutable: it is a runtime constant (final _lazy). The non-final constructor argument bool? lazy does not change the fact that _lazy itself is immutable. Also, so far the overrides automatically make stuff non-lazy, but that could be changed by adding a lazy argument to:

   
   @visibleForTesting
   
   ArgProviderOverride<T, A> overrideWithValue(T value) =>
   
       ArgProviderOverride._(this, value, debugName: debugName);
   
   

2. const means compile-time constant. Immutable does not imply compile-time constant, it can also mean runtime constant. Indeed, the constructor should not be const because of that comment.

Remember that providers and argument providers are just identifiers. A matching Provider is created behind the scenes to manage argument providers. In the past we experienced bugs and inconsistencies in our WIP feature branches when we tried to make the constructor no longer immutable and set the state directly inside the Provider or ArgProvider (I don't remember the details, but it was something major). Unfortunately, the code as it is in the PR now will probably lead to bugs.

Probable kind of bug (I did not test it, so I might be wrong):

// Note: numberProvider is ((arg) => arg * 2) and lazy

testWidgets(..., (...) {

    ProviderScope(

          providers: [numberProvider(2)]

          child: ...

             List [

                // somehow this is run first

                ProviderScopeOverride(

                      overrides:[numberProvider.overrideWithValue((arg) => arg * 4)]

                      child: ...

                ),

                // ensure that the following is run second, after the override. Maybe some lazy screen or something like that.

                OtherWidget(inject numberProvider here...)

           ]       

    )

});

Problem: Inside OtherWidget, numberProvider will have ((arg) => arg * 4) instead of ((arg) => arg * 2), because the _overrideFn was set at the identifier level. The actual internal Provider was not created when you specified numberProvider(2); instead, since it is lazy, the internal Provider was created when you tried to inject the identifier provider for the first time following the override (where I wrote inject numberProvider here...).

For the same reason, also this kind of structure probably won't work.

// Note: numberProvider is ((arg) => arg * 2) and it can be either lazy or strict

testWidgets(..., (...) {

     List [

        // somehow this is run first

        ProviderScopeOverride(

              overrides:[numberProvider.overrideWithValue((arg) => arg * 4)]

              child: ...

        ),

        // ensure that the following is run second, after the override. Maybe some lazy screen or something like that.

        ProviderScope(

            providers: [numberProvider(2)]

            child: OtherWidget(inject numberProvider here...) // value will be 8 instead of 4

        )

   ]       

});

Can you add such tests, so we can test my hypothesis?

No idea what do you mean in the following content. overrideWithValue takes a T value, it is not a function that gives the argument. That's why the user opened the issue.
So I didn't understand what to test

[manuel-plavsic]

I meant overrideWithFunction. I copied pasted from the snippet in the issue without adapting.

Edit: I updated it in #36 (comment)