Missing default value on List-typed app-state field generates malformed app_state.dart (analyzer errors: undefined 'value', 'null' as identifier, undefined 'updateFn'

[windlesam92-hue]

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

Declaring a new app-state field of type List<Document> (a document-reference list) without an explicit default value causes FlutterFlow's codegen to generate malformed Dart in app_state.dart. The generated code around the field's update-helper function (e.g. updateXAtIndex-style helper) contains broken syntax — the literal word null appears to be substituted into a name/identifier slot instead of a value slot. This produces multiple analyzer errors in the live generated code:

undefined_identifier: Undefined name 'value'
expected_identifier_but_got_keyword: 'null' can't be used as an identifier because it's a keyword
expected_token: Expected to find ')'
undefined_method: The method 'updateFn' isn't defined for the type 'FFAppState'

This breaks compilation of the generated project.

Expected Behavior

FlutterFlow's app-state codegen template should either (a) require/enforce a default value for List-typed app-state fields at declaration time, rejecting the field or prompting for a default rather than silently generating broken code, or (b) correctly handle a List-typed field with no default by generating a valid empty-list default internally, without producing malformed syntax.

Steps to Reproduce

In a FlutterFlow project, add a new app-state field of type List<Document<[some collection]>> (a list of document references) without specifying a default value.
Push/export the project and regenerate code (flutterflow ai run or equivalent codegen export).
Inspect the generated lib/app_state.dart — observe malformed syntax around the new field's update-helper function.
Run a Dart analyzer against the generated code and observe the errors listed above.

Reproducible from Blank

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

Bug Report Code (Required)

IT4shcmAx491ofpE15DUY/lR/SQWC0AkaI0ascp/bxIgGIDzPOw+ZPWlYhdtUvWkTXNUJ0SmmXI0w6nxkvzhLvkqIgeCbIhy1bpuTQqUeE+ua5OBDZeSf3ElEe5YGmLF1MK7vxRCKs9aL3su70yQIei/TgjsH5v4ImdISq/LZO4=

Visual documentation

Environment

FlutterFlow version: SDK 0.0.40 (latest build as of this session)
Platform: FlutterFlow AI SDK / CLI (flutterflow ai), used via Claude Code MCP integration
Operating system: Windows

Additional Information

This was discovered while adding a blockedUsersRefs field (List<Document>, no default) to support a "Blocked Users" settings feature. Every other List-typed app-state field already in this project (sessionSwipedGroups, feedGroupIds, discoveryDeckGroupIds) is List and was declared with a default value — this appears to be the first List<Document> field in the project, and the first without a default, which is what surfaced the bug. A workaround (setting an explicit '[]' default directly on the field) has been prepared but not yet verified, because the remote flutterflow ai validate service has separately been returning a generic "Unknown error" on repeated attempts around the same time — possibly an unrelated, concurrent platform issue, but flagging in case it's connected.

[windlesam92-hue]

Update: found a second, independent failure mode on the same field

While working around this, we found a related but distinct bug on the same blocked_users field (List<DocumentReference>, self-referential). This one surfaces earlier, at compileDslApp validate-time, rather than during codegen export — so it's a separate code path hitting the same underlying self-referential-type issue.

I now have the run ID (2026-08-02T22-53-54-033-pdsq11) for the minimal repro. Here's the finalized report:

---

Addition to: blockedUsersRefs codegen bug — related Stack Overflow at validate-time

Summary: A second, independent failure mode on the same field, reproduced today. Distinct from the previously-reported codegen-export bug (which surfaces during generated_code export / app_state.dart generation). This one surfaces earlier, during compileDslApp validation, before any push — 100% reproducible, and now isolated to its minimal form.

Minimal repro:
Attach a page-load (ON_INIT_STATE) action to any page via the FlutterFlow AI SDK, where an app-state field's value is bound to FFVariableSource.FIREBASE_AUTH_USER → FFAuthVariable_AuthProperty.USERS_DATA_FIELD → usersDataField: blocked_users (on the users collection). No other operation needs to be chained onto it.

FFVariable(
source: FFVariableSource.FIREBASE_AUTH_USER,
baseVariable: FFBaseVariable(
auth: FFAuthVariable(
property: FFAuthVariable_AuthProperty.USERS_DATA_FIELD,
usersDataField: FFIdentifier(name: 'blocked_users', key: /* field key */),
),
),
)

Result: compileDslApp fails with Error: Stack Overflow. No further detail is surfaced by the API.

Isolation performed (project social-rise-ms2dix):

┌───────────────────────────────────────────────────────────────────────────────────────────────┬─────────────────┐
│ Variant │ Result │
├───────────────────────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Page-load trigger writing a literal '0' to an app-state Integer field (no auth-user binding │ ✅ Passes │
│ at all) │ │
├───────────────────────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Page-load trigger writing the plain, unmodified USERS_DATA_FIELD → blocked_users binding, no │ ❌ Stack │
│ operations chained │ Overflow │
├───────────────────────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Same binding with a listNumItems (list-length) operation chained on top │ ❌ Stack │
│ │ Overflow │
├───────────────────────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│ Same binding used to populate both blockedUsersRefs and blockedUsersCount together │ ❌ Stack │
│ │ Overflow │
└───────────────────────────────────────────────────────────────────────────────────────────────┴─────────────────┘

This rules out listNumItems/any chained operation as a factor — the binding itself, with nothing else attached, is sufficient to reproduce the failure. The trigger/page-load-action mechanism is otherwise fine.

Suspected root cause: blocked_users is typed List<DocumentReference> — a self-referential field: the users collection has a field whose type points back to users itself. The equivalent binding against a non-self-referential field on the same collection (friends_only_messaging, a Boolean) already works and is live in this project (settingsPage's messagingFriendsOnlyCache init action uses the identical FIREBASE_AUTH_USER/USERS_DATA_FIELD shape successfully). This strongly suggests the compiler recurses infinitely while resolving the field's type against its own collection schema, and that this may share a root cause with the previously-reported blockedUsersRefs (settingsPage's messagingFriendsOnlyCache init action uses the identical FIREBASE_AUTH_USER/USERS_DATA_FIELD shape successfully). This strongly suggests the compiler recurses infinitely while resolving the field's type against its own collection schema, and that this may share a root cause with the previously-reported blockedUsersRefs codegen-export bug — both involve this same self-referential field, just hit through different code paths (validate-time binding resolution vs. codegen export).

Environment: FlutterFlow AI SDK, project social-rise-ms2dix, via flutterflow ai validate (dry-run, no push). Runs logged locally in .flutterflow/runs.jsonl, with archived DSL source in .flutterflow/history//edit.dart:

• 2026-08-02T22-53-54-033-pdsq11 — minimal repro (plain binding, no operations).
• 2026-08-02T22-35-20-789-bkc3hs — binding + listNumItems.
• 2026-08-02T22-32-23-636-njgrsl — full original repro (both app-state fields).

Flagging here rather than as a separate issue since it looks like the same root cause (compiler recursing on the self-referential type), just triggered through a different mechanism (auth-user-field binding resolution vs. codegen export).

[windlesam92-hue]

Addition 2 to: blockedUsersRefs codegen bug — confirmed build-breaking, project-wide impact

Summary: A third data point on this field, and the most concrete yet: a literal build failure with an exact error message, confirming the malformed codegen doesn't just corrupt app_state.dart in isolation — it breaks the entire app build, blocking every downstream consumer of that build. Test Pilot is one such consumer: no test, in any group, for any feature, can currently run against this project.

Repro: Start a Test Pilot run against project social-rise-ms2dix (any group). The run fails during the build phase, before any test logic executes (passed: 0, failed: 0 — it never got that far):

Could not format because the source could not be parsed:

line 314, column 36 of .: 'null' can't be used as an identifier because it's a keyword.
│
314 │ void addToBlockedUsersRefs(null value) {
│ ^^^^

line 318, column 37 of .: 'null' can't be ust's a keyword.
│
318 │ void removeFromBlockedUsersRefs(null value) {
│ ^^

line 328, column 7 of .: 'null' can't be used as an identifier because it's a keyword.
│
328 │ null Function(null) updateFn,
│ ^^^^

line 333, column 53 of .: 'null' can't be used as an identifier because it's a keyword.
│
333 │ void insertAtIndexInBlockedUsersRefs(int index, null value) {
│ ^^^^

What this confirms: blockedUsersRefs's generated list-mutation helpers (addTo*, removeFrom*, insertAtIndex*, the updateFn typedef) are emitting the literal token null where the field's element type (Document, i.e. a DocumentReference) should be — almost certaidefault value, so codegen has nothing toinfer the type from at this call site. The resulting app_state.dart is not just semantically wrong, it's syntactically
invalid Dart — it fails to parse, which is wher than merely producingbroken-but-compiling code.

Impact, precisely stated: This is not scoped to pages or features that reference blocked_users. Because app_state.dart is a single file shared by the whole app, a parse failure in it fails the entire app build. Concretely, right now on this project:

• The generated_code/ export/refresh path fa
• compileDslApp validation fails when any new action binds to blocked_users via FIREBASE_AUTH_USER/USERS_DATA_FIELD (previous addition — Stack Overflow, a separate, likely-related failure mode in the validator).
• Test Pilot cannot build or run any test inthis addition) — confirmed via a real run(runId: 3OZkhV6s4RvSOa7v0WuE, project social-rise-ms2dix), which failed at the build step with the exact error above
  before executing a single test.

Environment: FlutterFlow AI SDK, project social-rise-ms2dix, via testpilot.run (MCP) / flutterflow ai test-pilot run. Run id 3OZkhV6s4RvSOa7v0WuE.

[windlesam92-hue]

Subject: Update — 4th confirmed symptom for the blockedUsersRefs issue (project social-rise-ms2dix)

Following up on the blockedUsersRefs bug reported earlier — a List<Document> app-state field with no default value, combined with users.friends / users.bential List<DocumentReference> fieldspointing back into the same collection.

Previously confirmed:

1. SDK local compiler — binding any new action to blocked_users throws Error: Stack Overflow during compilation. 2. Dart codegen — the generated app_state.daaddToBlockedUsersRefs(null value) { ... }, agenuine Dart parse error that breaks the entire app build (12 analyzer errors).
2. Test Mode — hits the identical compiled-build failure as Radio button initial value is blank #2, confirmed manually in the FlutterFlow editor.

New — 4th confirmed symptom:
4. The FlutterFlow web builder's own canvas he only page in the project with widgetsbound to blockedUsersRefs) threw an error once, and now loads blank/black on every subsequent open, no error shown. We inspected the page's compiled proto directly and confirmed the widget tree itself is structurally valid — nothing malformed. The distinguishing factor is thatin the project with a widget generator boundto blockedUsersRefs, plus two per-item field accessors (photo_url, display_name) that require resolving the field's
element type through the full users schema —pe shape already implicated in symptom #1.

We believe this is the same root cause surfacing in a third independent code path — the SDK compiler, Dart codegen, and now the builder's own canvas resolution all appear to trip on the same missing-default + self-referential-type combination — rather than a new, unrelated bug. Confirmed across four independent surfaces now; would appreciate an update on fix status.