Auto-generated default implementation for a Library Action Parameter does not match its declared signature when the parameter has additional required named arguments

[vdevc]

Can we access your project?

• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

In a Library project, an "Action Parameter" (a function-typed Library Value that host apps are expected to override) can be declared with a signature beyond the base (BuildContext context), e.g. by adding a required named argument such as {required String? value}. FlutterFlow automatically generates a default implementation for every Action Parameter so the library compiles/previews standalone before any consuming app overrides it. However, this auto-generated default is always produced with the base signature (BuildContext context) only — it does not account for any additional required named parameters that were added to the Action Parameter's declared type.

This creates a type mismatch between the field's declared type (e.g. Future Function(BuildContext, {required String? value})) and the auto-generated default assigned to it (Future<Null> Function(BuildContext)), which the Dart analyzer correctly flags. However, the FlutterFlow editor surfaces this as a generic error banner ("Errors found in custom function "".") attached to an arbitrary custom function in the project, rather than pointing at the actual Action Parameter / its default implementation. This makes the error very difficult to locate and diagnose, since the flagged custom function is unrelated and contains no issue itself.

The error does not block compilation of consuming apps, because any host project that overrides the Action Parameter supplies its own correctly-typed implementation, and the broken default is never actually invoked. It only shows up as a persistent, seemingly unexplainable error inside the library project's own editor.

Expected Behavior

Either:

1. The auto-generated default implementation for an Action Parameter should be kept in sync with its currently declared parameter list, including any required named parameters, so its signature always matches the field's declared type; or
2. FlutterFlow should not attempt to auto-assign a default implementation for Action Parameters that include required named parameters, since such parameters are commonly declared as required/non-nullable specifically to force consuming apps to provide their own implementation, and no meaningful default can exist for them.

In either case, if an error is still surfaced, it should be attributed to the actual Action Parameter / its default implementation, not to an unrelated custom function that happens to be open or nearby in the editor's internal representation.

Steps to Reproduce

1. Create a Library project in FlutterFlow.
2. Define an Action Parameter (a function-typed Library Value) with the base signature (BuildContext context).
3. Edit that Action Parameter to add a required named argument, e.g. {required String? value}.
4. Open the library project's editor and open any custom function (unrelated to the Action Parameter).
5. Observe an error banner such as: Errors found in custom function "<unrelated function name>".
6. Opening the flagged function shows an analyzer error along the lines of: A value of type 'Future<Null> Function(BuildContext)' can't be assigned to a variable of type 'Future<dynamic> Function(BuildContext, {required String? value})'. The function that was opened contains no actual issue.
7. Confirm that a separate project consuming this library, which overrides the Action Parameter with a correctly-typed implementation, compiles and runs without any error — the problem is isolated to the library project's own editor/analysis.

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

IT48hcj6w5d2odxE17Xyb/lvoCMvKUc7U5Ir1O1HbxU8J5zKB+wAYvf7P1FWTLzkd2xbeWKghmEz/PfqiuDxKcAqCwubb4c/+c1+WAv/cEO7Vq6pPrmBfW1SHplMGnGM1qSVnCRTPulhc1Ya3U2yGvC+fHHdNub4IkY/AOSLKdeK2SrDX1iXc2URm05KZDPz

Visual documentation

and, after tapping on it

Environment

- FlutterFlow version: any
- Platform: macos app
- Browser name and version:
- Operating system and version affected:

Additional Information

• This reproduces for any Action Parameter that has one or more required named parameters beyond the base BuildContext context argument; Action Parameters with only (BuildContext context) are unaffected, since the auto-generated default matches that simpler signature.
• The issue appears purely cosmetic/non-blocking for downstream consumers, but it is persistent and cannot be resolved from within the editor, since the default implementation is auto-generated and not directly user-editable.
• The misleading attribution to an unrelated custom function makes root-causing this issue significantly harder for library authors who are not already familiar with how Action Parameter defaults are generated internally.