TrustedDriversPage / Addtrusteddriverpage blank-render bug + two FlutterFlow AI SDK toolchain issues found investigating it

[anghanrealtech]

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

Issue 1 — Blank page render (product bug):
TrustedDriversPage renders completely blank in Test Mode — no driver list, no empty state, and no "+ Add Trusted Driver" button — despite all three being present and unconditional in the page's proto and generated code. Console repeatedly throws two Flutter framework assertions: mouse_tracker.dart:199 (assert(!_debugDuringDeviceUpdate)) and box.dart:2251 (assert(hasSize, 'RenderBox was not laid out: $this')).

Issue 2 — FlutterFlow AI SDK: reverting a script's call site does not undo prior structural mutations:
Deleting a mutation function's call site from a local dsl/edit.dart script and re-running flutterflow ai run gives every outward signal of a successful revert (validate and test pass, push succeeds, no errors/warnings) — but the live project's widget tree is left unchanged from its pre-"revert" (broken) state. changeSummary.modifiedPages in the run's trace confirms the pages in question were never touched by that push.

Issue 3 — FlutterFlow AI SDK: .byKey(...)-sourced ensureMovedTo moved the wrong node:
A second, sequential ensureMovedTo call targeting the same destination node as a prior call in the same editPage block moved a completely different, unreferenced widget (Container_qgzpnq8d — an entire live, data-bound page section) instead of the widget actually selected by its key (Container_sy4ocfr3). The push validated and reported success with no indication anything had gone wrong.

Expected Behavior

Issue 1: The page should render its header, list (or empty state), info banner, and CTA button regardless of the databaseRequest-bound StreamBuilder's loading→content swap. That swap should not be able to crash or blank out unrelated, already-laid-out sibling widgets on the same page.

Issue 2: Either flutterflow ai run should apply the DSL script's operations idempotently in a way that a removed structural-mutation call does get undone on the next push, or — if that's architecturally not how the tool works — the CLI should surface a clear signal (warning, diff, or explicit no-op notice) when a page that was previously modified by a script is no longer touched by it at all, rather than reporting a clean success indistinguishable from a real revert.

Issue 3: A .byKey(...) selector should deterministically resolve to the node with that exact key, unaffected by other ensureMovedTo operations run earlier in the same script — matching the documented behavior that .byKey(...) (unlike .byPath(...)) is immune to positional staleness within a single edit run.

Steps to Reproduce

Issue 1:

1. Open TrustedDriversPage in Test Mode (web, Chrome).
2. Trigger the page's databaseRequest-bound ListView to swap from its loading CircularProgressIndicator to its populated ListView.builder state.
3. During that swap, generate a pointer event — reproduced consistently via: (a) a mouse click, (b) a mouse-flick away from the canvas, and (c) Chrome touch emulation. All three trigger the same failure.
4. Observe: the page renders blank; console shows the mouse_tracker.dart:199 / box.dart:2251 assertions.

Issue 2:

1. In a FlutterFlow AI SDK workspace, author a DSL edit script function that performs a structural change (e.g., moves widgets, deletes a node) on a page, and push it (flutterflow ai run).
2. Confirm the change is live (re-export/read generated_code/ for that page).
3. Remove the function's call site from the script (but not the function itself, or any inverse logic — there is none).
4. Re-run flutterflow ai run with a commit message indicating intent to revert.
5. Observe: validate/test/run all report success. Inspect .flutterflow/traces/.json → changeSummary.modifiedPages for that run: the page from step 1 is absent. Re-read generated_code/ for that page: it still reflects the step-1 change, unreverted.

Issue 3:

1. In one page.editPage(...) block, issue two sequential ensureMovedTo calls, each sourced via a distinct .byKey(...) selector, both targeting the same destination parent node:
   final pickerColumn = addTrustedDriverPage.widgets.byKey('Column_to364g2l').single;
   page.ensureMovedTo(addTrustedDriverPage.widgets.byKey('Container_md5bob3z').single, pickerColumn, index: 1);
   page.ensureMovedTo(addTrustedDriverPage.widgets.byKey('Container_sy4ocfr3').single, pickerColumn, index: 2);
2. Validate and push.
3. Inspect the live tree before/after (flutterflow ai inspect --page --tree).
4. Observe: the first call's target (Container_md5bob3z) moves correctly. The second call's stated target (Container_sy4ocfr3) never moves — instead, an unrelated node (Container_qgzpnq8d, in our case a full StreamBuilder-bound list section three levels deep elsewhere in the tree) is moved into the destination instead.

Reproducible from Blank

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

Bug Report Code (Required)

ITFTi87huIZNod9c+KX5LMZKliMsCUMdXOczitVEew4bCIj4EIYqeszBSEpWOOazaHNIGlabmngK+fzOvd7tJPY7PSiqY65z1bh+ZhPPbGGtMoSnPruKfUZCI/tjBXa8y8GvvxYlPrRuc04u20OqJu6iST6Cf9qOYwx5e6fDbOY=

Visual documentation

Environment

- Project ID: my-ride-p9xvlc
- Affected pages: TrustedDriversPage, Addtrusteddriverpage
- FlutterFlow AI SDK version: 0.0.40
- Dart version: 3.10.7
- Test surface: FlutterFlow Test Mode, web (Chrome) — reproduced via mouse click, mouse-flick, and Chrome touch emulation
- Tooling: FlutterFlow AI SDK CLI (flutterflow ai validate / test / run / inspect), local DSL workspace (dsl/edit.dart)

Additional Information

• Upstream Flutter issues matching Issue 1's signature: Mouse Tracking throwing exceptions for widgets inside a ListView that are listening for hover events  flutter/flutter#30744, #64129, #66887, #105031.
• Confirmed no project-level fix point exists for Issue 1: a full source search of the FlutterFlow-Desktop-bundled Flutter SDK returned zero matches for CircularProgressIndicator anywhere reachable from this project — the loading→content swap is generated server-side by FlutterFlow's own codegen template for every databaseRequest-bound widget, outside workspace reach. We believe this needs a fix in that codegen template, or an upstream Flutter fix to land in the bundled SDK version.
• Mitigations attempted for Issue 1 (neither resolved it): (a) removing redundant SingleChildScrollView + shrinkWrap ListView nesting to shrink the race window — no observable effect; (b) isolating static widgets from the query-bound list section — made rendering worse and is what surfaced Issues 2 and 3 below.
• Reference commits (for your team's internal reproduction, project my-ride-p9xvlc):
  • CxkAgzqgTbTv0WsDYC0j — shrinkWrap mitigation (Issue 1 attempt, no effect)
  • U37DZravrQoQ3ZdQivJs — isolation attempt (made Issue 1 worse)
  • p9iW7w7pi8OLyK5kOM1b — the ineffective "revert" (Issue 2)
  • fOi9Vl9ogGxvma4HJJdL — the ensureMovedTo mistargeting (Issue 3)
  • RXupD8vER4xEZrYK0Ygo — final working correction, using raw proto operations instead of ensureMovedTo
• Severity note on Issues 2 & 3: both produced clean, successful-looking pushes with no errors or warnings, despite not doing what they appeared to do. Issue 3 in particular silently relocated a live, query-bound page section into the wrong part of a running page — we'd consider this higher severity than a validation failure precisely because it fails silently rather than loudly.
• Ask: primary priority is guidance/fix on Issue 1 (the product bug blocking this feature). Issues 2 and 3 are secondary but worth your engineering team's attention given their silent-failure characteristics — Issue 2 at minimum warrants a documentation callout so this revert pattern isn't assumed safe by other users; Issue 3 warrants investigation given it appears to contradict the documented .byKey() staleness-immunity guarantee.