R10 preflight false positive: FIRESTORE_REQUEST list-item bindings (FF Desktop's own pattern) not recognized — hard-blocks any DSL edit to affected pages (flutterflow_ai 0.0.39)

[glebsergeich-maker]

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

Component: FlutterFlow AI workspace SDK / CLI (flutterflow_ai 0.0.39, build fd345c8d), preflight lint R10 in lib/src/pipeline/wiring_review.dart, _checkListWiring, ~lines 203–205.

R10 ("List has a backend query but no child widget binds to list item data", severity critical → blocks the pipeline, no bypass flag) decides whether a query-backed ListView/GridView child binds to list-item data by grepping the child's describeNode proto dump for the literal strings generatorVariable, generatorVar, or GENERATOR_VARIABLE.

FlutterFlow Desktop's own visual-builder authoring does not produce any of those. When you bind a list child's params to the current item in the builder, it emits FFVariable(source: FIRESTORE_REQUEST, operations: [accessDocumentField(...)], nodeKeyRef: <list node key>) — no FFGeneratorVariable on the list node, no GENERATOR_VARIABLE source anywhere. The same pattern appears in long-standing, working pages of this project.

Result: any page whose query-backed list uses this (builder-native) pattern permanently fails R10 — but only when touched, since preflight scopes to touched entities. The page is correctly wired and renders fine; the block is purely the client-side lint.

Attempting to satisfy R10 from the DSL side by grafting FFGeneratorVariable onto the existing list node + GENERATOR_VARIABLE param bindings fails server-side validation ("Dynamic children variable not properly configured for ListView" / "parameter ... not set properly") — the lint and the server accept disjoint shapes for brownfield lists, so there is no script-side workaround.

Expected Behavior

R10 should recognize FIRESTORE_REQUEST-sourced child bindings whose nodeKeyRef targets the query-backed list node as valid list-item wiring (it is the shape FF Desktop itself authors), or downgrade to warning.

Suggested minimal fix:

--- a/lib/src/pipeline/wiring_review.dart
+++ b/lib/src/pipeline/wiring_review.dart
@@ -202,7 +202,8 @@
           .join('\n');
       if (!childDescs.contains('generatorVariable') &&
           !childDescs.contains('generatorVar') &&
-          !childDescs.contains('GENERATOR_VARIABLE')) {
+          !childDescs.contains('GENERATOR_VARIABLE') &&
+          !childDescs.contains('FIRESTORE_REQUEST')) {
         warnings.add(

(A stricter fix would match FIRESTORE_REQUEST variables whose nodeKeyRef equals the list node key, rather than a bare substring check.)

Steps to Reproduce

1. Have a page with a ListView backed by a Firestore query, whose child widget (e.g. a component instance) binds params to the current list item via the FF Desktop visual builder (FIRESTORE_REQUEST + nodeKeyRef pattern).
2. Author any DSL edit touching that page (even an unrelated one-line patch) and run flutterflow ai run / flutterflow ai validate.
3. Preflight fails: Preflight failed: <Page> — List has a backend query but no child widget binds to list item data

Note: not reproducible from a blank project as such — it requires a page whose list-item bindings were authored in the FF Desktop visual builder (the pattern above), then any CLI edit touching that page.

Reproducible from Blank

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

Bug Report Code (Required)

N/A — CLI/SDK preflight bug (flutterflow_ai 0.0.39), not a widget/editor bug; no widget tree involved. Failing CLI run ID: 2026-07-21T02-02-30-318-fev0qz, project easy-care-5a4dwj.

Visual documentation

CLI-only bug — no UI to screenshot. Exact terminal output from the failing run:

Preflight failed: NamedParentpaymentsStructurePage — List has a backend query but no child widget binds to list item data

Failing run ID: 2026-07-21T02-02-30-318-fev0qz (project easy-care-5a4dwj) — full trace available via flutterflow ai support bundle on request.

Environment

- flutterflow_ai SDK / CLI: 0.0.39 (build fd345c8d), env prod
- Workspace: FlutterFlow AI DSL workspace (`flutterflow ai` CLI / MCP)
- Platform: macOS (Apple Silicon), zsh
- Project: easy-care-5a4dwj, branch main
- FF Desktop used to author the affected page's original bindings

Additional Information

Impact: every FlutterFlow AI / MCP user editing a page that was originally authored in the FF Desktop builder and contains a query-backed list is hard-blocked from pushing ANY edit to that page (preflight has no bypass flag). We hit this while shipping a payments fix; the only workaround was hand-patching the vendored SDK's wiring_review.dart for a single push and reverting.

Permission granted to access project easy-care-5a4dwj to investigate.

[glebsergeich-maker]

Additional evidence: the false positive is not specific to one page - it fires on any page whose query-backed list uses builder-authored (pattern A) item bindings.
Today the same R10 preflight failure blocked an edit to a different page (HomeScreen) in the same project (easy-care-5a4dwj, SDK 0.0.39 / build fd345c8d):

[FAIL] preflight (0ms) -- Preflight failed: HomeScreen. - List has a backend query, but no child widget binds to list item data

• Failing run ID: 2026-07-21T03-58-45-411-msc31d (dry-run validate; the edit itself was a one-line action-chain change, unrelated to any list)
• HomeScreen's lists bind their children via FIRESTORE_REQUEST + nodeKeyRef (the shape FF Desktop authors), which the R10 substring check (generatorVariable / GENERATOR_VARIABLE) never matches.
• Practical impact: every DSL edit touching any page with such a list is blocked, since preflight re-checks all touched pages. We're currently working around it by temporarily patching wiring_review.dart per push.