Can we access your project?
Current Behavior
compileDslApp (used by both flutterflow ai validate and flutterflow ai run) fails with a validation error on project lemons-ktggxj, page OrderDetail:
Task "compileDslApp" failed: Validation failed: Scaffold 'OrderDetail' [key: Scaffold_0wgtnjmj] — Action in OrderDetail has an output variable with the same name as that of another widget.
- Go to WiderrufArticlesListView.
- Go to GroupedOrdersListView.
- Go to OrderCardArticlesListView.
- Multiple primary scrollable widgets nested within each other. Typically only one should be set as primary.
- Go to Column.
- Firebase is currently not supported on Windows.
- See query on Column.
Most notably: the exact same project state was validated as passing and then failing ~17 minutes apart, with no push in between (see "Steps to Reproduce" for the timestamped evidence). This points to a server-side consistency/caching issue in the compileDslApp check rather than a problem in our project.
The project runs cleanly in the Builder itself (Start/Run shows no validation error). The error only occurs via the AI SDK compile path (compileDslApp), used identically by validate and run, even after a full Builder session restart.
Expected Behavior
compileDslApp should return a consistent validation result for an unchanged project state. It should not pass at one point in time and fail on the identical state ~17 minutes later with no intervening changes. Additionally, when an "output variable name collision" error is reported, the validator should ideally name the two specific colliding identifiers, since this isn't derivable from the DSL/inspect export.
Steps to Reproduce
- Push project state to lemons-ktggxj (push Z6RzB0XB, App State migration) — flutterflow ai run confirms compileDslApp: ok at 2026-08-04T10:28:19Z.
- No further pushes/mutations occur — only read-only
flutterflow ai inspect calls.
- Run
flutterflow ai validate (dry-run) at 2026-08-04T10:45:01Z against the same, unchanged project state — compileDslApp: FAIL with the error quoted in "Current Behavior".
- Repeat
flutterflow ai validate — fails identically, 8 times in a row, including after a full browser/Builder session restart, most recently reconfirmed 2026-08-04 ~14:0x UTC.
Additional isolation steps performed (see "Additional Information"):
5. Temporarily fully disable all newly added DSL code (early return) — error persists identically.
6. Rename (DSL name only, no logic change) each of the three widgets named in the error hints, plus the only remaining default-named "Column" widget — core error persists identically in all cases.
7. Duplicate the affected page (OrderDetail → OrderDetail_Test, identical content, new internal page ID) and validate — error occurs in identical form on both pages, just with the page name substituted.
Reproducible from Blank
Bug Report Code (Required)
N/A — this is a server-side validation inconsistency (compileDslApp), not reproducible via a local code snippet. Full technical evidence (timestamps, ruled-out causes) is in "Additional Information".
Visual documentation
Environment
* FlutterFlow version: v7.0.64+ released Juli 30, 2026
* Platform: Web (tested), plus AI SDK / CLI (flutterflow ai validate/run) — the error occurs specifically via the CLI/AI SDK compile path, not in the Builder itself
* Browser name and version (web): Firefox 153.0.1
* Operating system and version (desktop): Windows 11 Pro 24H2
Additional Information
Local validator infrastructure ruled out as the cause: Windows x64 is not supported by the local validator (see Environment) — there is no local cache. Every validate/run invocation goes directly against the remote FlutterFlow compile service. The observed inconsistency therefore cannot be a local caching issue — it must originate server-side.
Ruled out as the cause — our own code:
- Error persists identically when newly added DSL code is temporarily fully disabled (early return, code never executes).
- All 15 output-variable names across the entire project (12 pages + 2 components) were programmatically cross-checked against every widget/identifier name in the project — no match found.
- Targeted rename tests on all widgets named in the error hints: no change to the core error, only cosmetic hint-label updates.
Additional test — page duplication: OrderDetail duplicated as OrderDetail_Test (identical content, new internal page ID/Scaffold key). Error occurred in identical form on both pages — tied to page content, not to a specific internal page ID. Rules out a "recreate the page and delete the original" workaround.
FlutterFlow status page: no incidents reported at time of testing.
Question: Since the error has provably occurred without any change to our project, is not derivable from local caching, and is independent of the specific page ID — could someone confirm whether this is a known server-side caching/consistency effect in compileDslApp validation, and identify which two specific names/widgets are being detected as colliding?
Can we access your project?
Current Behavior
compileDslApp(used by bothflutterflow ai validateandflutterflow ai run) fails with a validation error on projectlemons-ktggxj, pageOrderDetail:Task "compileDslApp" failed: Validation failed: Scaffold 'OrderDetail' [key: Scaffold_0wgtnjmj] — Action in OrderDetail has an output variable with the same name as that of another widget.
Most notably: the exact same project state was validated as passing and then failing ~17 minutes apart, with no push in between (see "Steps to Reproduce" for the timestamped evidence). This points to a server-side consistency/caching issue in the compileDslApp check rather than a problem in our project.
The project runs cleanly in the Builder itself (Start/Run shows no validation error). The error only occurs via the AI SDK compile path (compileDslApp), used identically by validate and run, even after a full Builder session restart.
Expected Behavior
compileDslAppshould return a consistent validation result for an unchanged project state. It should not pass at one point in time and fail on the identical state ~17 minutes later with no intervening changes. Additionally, when an "output variable name collision" error is reported, the validator should ideally name the two specific colliding identifiers, since this isn't derivable from the DSL/inspect export.Steps to Reproduce
flutterflow ai inspectcalls.flutterflow ai validate(dry-run) at 2026-08-04T10:45:01Z against the same, unchanged project state — compileDslApp: FAIL with the error quoted in "Current Behavior".flutterflow ai validate— fails identically, 8 times in a row, including after a full browser/Builder session restart, most recently reconfirmed 2026-08-04 ~14:0x UTC.Additional isolation steps performed (see "Additional Information"):
5. Temporarily fully disable all newly added DSL code (early return) — error persists identically.
6. Rename (DSL name only, no logic change) each of the three widgets named in the error hints, plus the only remaining default-named "Column" widget — core error persists identically in all cases.
7. Duplicate the affected page (OrderDetail → OrderDetail_Test, identical content, new internal page ID) and validate — error occurs in identical form on both pages, just with the page name substituted.
Reproducible from Blank
Bug Report Code (Required)
N/A — this is a server-side validation inconsistency (compileDslApp), not reproducible via a local code snippet. Full technical evidence (timestamps, ruled-out causes) is in "Additional Information".
Visual documentation
Environment
Additional Information
Local validator infrastructure ruled out as the cause: Windows x64 is not supported by the local validator (see Environment) — there is no local cache. Every validate/run invocation goes directly against the remote FlutterFlow compile service. The observed inconsistency therefore cannot be a local caching issue — it must originate server-side.
Ruled out as the cause — our own code:
Additional test — page duplication: OrderDetail duplicated as OrderDetail_Test (identical content, new internal page ID/Scaffold key). Error occurred in identical form on both pages — tied to page content, not to a specific internal page ID. Rules out a "recreate the page and delete the original" workaround.
FlutterFlow status page: no incidents reported at time of testing.
Question: Since the error has provably occurred without any change to our project, is not derivable from local caching, and is independent of the specific page ID — could someone confirm whether this is a known server-side caching/consistency effect in compileDslApp validation, and identify which two specific names/widgets are being detected as colliding?