FlutterFlow AI SDK preflight validation blocks legitimate SDK edits with apparent false positives

[Hellie3]

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

FlutterFlow AI SDK preflight validation blocks legitimate SDK edits with apparent false positives

Environment

• FlutterFlow AI CLI / SDK
• Codex CLI on Windows 11 PowerShell
• Model used: GPT-5.5 High / Medium
• Project ID: hellix-system-ygwfbv

Goal

A very narrow scoped refactor was attempted on the exercise page:

Replace references to:

• setDoc.setType

with:

• exerciseDoc.type

The change was intentionally limited to:

• exact field references,
• exact action outputs,
• exact page scope,
• no UI changes,
• no schema changes,
• no collection changes,
• no component API changes.

What happened

The edit script compiled successfully and tests passed, but flutterflow ai validate and flutterflow ai run failed because of unrelated project-wide preflight validation errors.

The SDK repeatedly blocked the push before mutation.

Commands used

• flutterflow ai test
• flutterflow ai validate dsl/edit.dart --project-id hellix-system-ygwfbv
• flutterflow ai run dsl/edit.dart --project-id hellix-system-ygwfbv

Observed preflight blockers

R1 — “Component parameter declared but not referenced”

Many component params were flagged as unused, including:

• ExerciseManager.showReplyMethodCP
• ExerciseManager.showQuestionCP
• ExerciseManager.correctAnswerDisplayWidget
• EnglishDynamicTextField.initialValue
• EnglishDynamicTextField.onFocusChange
• EnglishDynamicTextField.resetOnSubmit
• many others

However, generated Dart code confirmed that at least some of these parameters ARE actually used at runtime.

Example:

• EnglishDynamicTextField.initialValue
• onFocusChange
• resetOnSubmit

were confirmed present in generated code and used by controller setup / widget logic.

This suggests the validator is producing false positives or missing references that exist in generated runtime code.

R10 — “ListView backend query not bound”

The validator flagged:

• Institute.InfoMainListView

claiming:

• the ListView had a backend query with no child binding to list item data.

However, generated Dart code showed the query output was actually used:

• infoMainListViewSchoolTokensRecord?.st2
• infoMainListViewSchoolTokensRecord?.tt1

This appears to be another false positive, possibly because the query is:

• singleRecord: true
  rather than a normal repeated list item binding.

State field warnings

Repeated warnings:

• State field uses listType wrapping a DataStruct. Use isList=true...

Many state variables were flagged even though Builder already showed:

• Data Type
• Is List = true

Toggling settings and re-saving from Builder did not remove warnings.

This may indicate older/internal serialization metadata that Builder displays correctly but the SDK validator still interprets as legacy encoding.

Important behavior observed

The SDK eventually allowed validation after local modification of:

• .flutterflow/sdk/flutterflow_ai/lib/src/pipeline/wiring_review.dart

where:

• R1 was downgraded from blocking error to warning,
• R10 was relaxed for single-record queries.

After that:

• validation passed,
• a push command succeeded,
• FlutterFlow Builder showed a new commit.

However:

• the resulting commit was a NO_OP.

SDK trace explicitly reported:

NO_OP: All tasks completed but no project changes were detected.
The project proto is identical before and after task execution.

So:

• the SDK pipeline created a commit entry,
• but no actual app mutation occurred.

Main issue

The current FlutterFlow AI preflight system appears too strict and/or inaccurate for existing mature projects with accumulated metadata history.

False positives can:

• block legitimate scoped edits,
• prevent AI-assisted refactors,
• and force developers to patch local SDK validator code to continue working.

Suggested improvements

1. Downgrade uncertain “unused parameter” findings to warnings.

2. Improve query-binding detection for:

   • single-record queries,
   • nested builder scopes,
   • indirect bindings.

3. Provide:

   • --skip-preflight
   • or scoped validation mode.

4. Distinguish:

   • runtime-breaking errors
     from:
   • metadata hygiene warnings.

5. Improve diagnostics by:

   • naming exact state fields causing warnings,
   • providing direct Builder navigation paths.

Additional note

The app itself continued to work during all of this. The issue appears specific to FlutterFlow AI SDK validation/preflight behavior rather than generated runtime behavior.

Expected Behavior

The tools shouldn't block the push based on false positives

Steps to Reproduce

1. clone my project
2. try to make the edits I tried (see attached files for the request)

Reproducible from Blank

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

Bug Report Code (Required)

FlutterFlow AI SDK preflight validation blocks legitimate SDK edits with apparent false positives ## Environment * FlutterFlow AI CLI / SDK * Codex CLI on Windows 11 PowerShell * Model used: GPT-5.5 High / Medium * Project ID: hellix-system-ygwfbv ## Goal A very narrow scoped refactor was attempted on the exercise page: Replace references to: * setDoc.setType with: * exerciseDoc.type The change was intentionally limited to: * exact field references, * exact action outputs, * exact page scope, * no UI changes, * no schema changes, * no collection changes, * no component API changes. ## What happened The edit script compiled successfully and tests passed, but flutterflow ai validate and flutterflow ai run failed because of unrelated project-wide preflight validation errors. The SDK repeatedly blocked the push before mutation. ## Commands used * flutterflow ai test * flutterflow ai validate dsl/edit.dart --project-id hellix-system-ygwfbv * flutterflow ai run dsl/edit.dart --project-id hellix-system-ygwfbv ## Observed preflight blockers ### R1 — “Component parameter declared but not referenced” Many component params were flagged as unused, including: * ExerciseManager.showReplyMethodCP * ExerciseManager.showQuestionCP * ExerciseManager.correctAnswerDisplayWidget * EnglishDynamicTextField.initialValue * EnglishDynamicTextField.onFocusChange * EnglishDynamicTextField.resetOnSubmit * many others However, generated Dart code confirmed that at least some of these parameters ARE actually used at runtime. Example: * EnglishDynamicTextField.initialValue * onFocusChange * resetOnSubmit were confirmed present in generated code and used by controller setup / widget logic. This suggests the validator is producing false positives or missing references that exist in generated runtime code. ### R10 — “ListView backend query not bound” The validator flagged: * Institute.InfoMainListView claiming: * the ListView had a backend query with no child binding to list item data. However, generated Dart code showed the query output was actually used: * infoMainListViewSchoolTokensRecord?.st2 * infoMainListViewSchoolTokensRecord?.tt1 This appears to be another false positive, possibly because the query is: * singleRecord: true rather than a normal repeated list item binding. ### State field warnings Repeated warnings: * State field uses listType wrapping a DataStruct. Use isList=true... Many state variables were flagged even though Builder already showed: * Data Type * Is List = true Toggling settings and re-saving from Builder did not remove warnings. This may indicate older/internal serialization metadata that Builder displays correctly but the SDK validator still interprets as legacy encoding. ## Important behavior observed The SDK eventually allowed validation after local modification of: * .flutterflow/sdk/flutterflow_ai/lib/src/pipeline/wiring_review.dart where: * R1 was downgraded from blocking error to warning, * R10 was relaxed for single-record queries. After that: * validation passed, * a push command succeeded, * FlutterFlow Builder showed a new commit. However: * the resulting commit was a NO_OP. SDK trace explicitly reported: > NO_OP: All tasks completed but no project changes were detected. > The project proto is identical before and after task execution. So: * the SDK pipeline created a commit entry, * but no actual app mutation occurred. ## Main issue The current FlutterFlow AI preflight system appears too strict and/or inaccurate for existing mature projects with accumulated metadata history. False positives can: * block legitimate scoped edits, * prevent AI-assisted refactors, * and force developers to patch local SDK validator code to continue working. ## Suggested improvements 1. Downgrade uncertain “unused parameter” findings to warnings. 2. Improve query-binding detection for: * single-record queries, * nested builder scopes, * indirect bindings. 3. Provide: * --skip-preflight * or scoped validation mode. 4. Distinguish: * runtime-breaking errors from: * metadata hygiene warnings. 5. Improve diagnostics by: * naming exact state fields causing warnings, * providing direct Builder navigation paths. ## Additional note The app itself continued to work during all of this. The issue appears specific to FlutterFlow AI SDK validation/preflight behavior rather than generated runtime behavior.

Visual documentation

Environment

- FlutterFlow version: v6.6.106
- Platform:Windows 11
- Browser name and version: Uing Powershell and Codex gpt-5.5 high
- Operating system and version affected: 
Edition	Windows 11 Home
Version	25H2
Installed on	‎30/‎10/‎2025
OS build	26200.8457
Experience	Windows Feature Experience Pack 1000.26100.304.0

Additional Information

It makes the MCP useless. And I need it for a lot of refactors.

[Hellie3]

These are the summaries of my chats (I burnt over 20$ on API tokens, yet it failed)
systemHellixPart1.txt
systemHellixPart2.txt

[Hellie3]

One more important point:

The fact that the agent modified SDK internals seems to me dangerous. AI agents should probably avoid mutating SDK internals.