Can we access your project?
Current Behavior
Since a recent update, using Generate Dynamic Children on a Wrap widget causes a fatal crash during runtime with a "Duplicate keys found" error.
The crash log states: Wrap has multiple children with key [String <'Column_rt1ruhp1'>].
The core issue is that FlutterFlow is completely ignoring any custom Value Key assigned to the immediate child of the Wrap. Even when explicitly assigning a unique identifier (like a UUID from a Supabase row, or Index in List using a Combine Text workaround) to the child widget (e.g., a Column or Container), the compiler forces its own auto-generated static key (like Column_rt1ruhp1) onto EVERY generated child, causing an inevitable collision.
Isolation test performed: > I created a brand new blank page, added a Wrap with a simple Container/Button inside, and generated dynamic children from a standard App State JSON list. Assigned $.id as the Value Key. It crashes in the exact same way. This was working perfectly yesterday.
Expected Behavior
The Wrap widget should correctly respect and apply the unique Value Key provided in the builder to each dynamically generated child. If no custom key is provided, the engine should automatically assign unique sequential keys under the hood to prevent duplication crashes, just like ListView and GridView do.
Steps to Reproduce
1.Create a Wrap widget.
2.Add a Column or Container as its direct child.
3.Use Generate Dynamic Children on the Wrap using any list.
4.Assign a unique Value Key to the child widget (e.g., Item ID).
5.Run the app.
6.App crashes with Duplicate Keys error pointing to a generic FlutterFlow auto-generated widget name.
Reproducible from Blank
Bug Report Code (Required)
IT4KlcrluJdPm9tK17r+avlF9Cg4QzsnbIJFlutTeA83GKnkG7l3V877QFVUOcvnTXw3PmejhnwX/Mr3vuLtMuw4KSqBbqpz+pZhWDrMezm7Rr6OEpS3b3QnAd1QJhGC5p2JnhEnIu9iSiFiwU6MevK8cBLvH4z7IFgdG+aoXdeK2SrDX1iXc2URm05KZDPz
Visual documentation
Environment
- FlutterFlow version: latest version jun 2 2026
- Platform: Web
- Browser name and version: Chrome148.0.7778.217
- Operating system and version affected: Windows 11
Additional Information
No response
Can we access your project?
Current Behavior
Since a recent update, using Generate Dynamic Children on a Wrap widget causes a fatal crash during runtime with a "Duplicate keys found" error.
The crash log states: Wrap has multiple children with key [String <'Column_rt1ruhp1'>].
The core issue is that FlutterFlow is completely ignoring any custom Value Key assigned to the immediate child of the Wrap. Even when explicitly assigning a unique identifier (like a UUID from a Supabase row, or Index in List using a Combine Text workaround) to the child widget (e.g., a Column or Container), the compiler forces its own auto-generated static key (like Column_rt1ruhp1) onto EVERY generated child, causing an inevitable collision.
Isolation test performed: > I created a brand new blank page, added a Wrap with a simple Container/Button inside, and generated dynamic children from a standard App State JSON list. Assigned $.id as the Value Key. It crashes in the exact same way. This was working perfectly yesterday.
Expected Behavior
The Wrap widget should correctly respect and apply the unique Value Key provided in the builder to each dynamically generated child. If no custom key is provided, the engine should automatically assign unique sequential keys under the hood to prevent duplication crashes, just like ListView and GridView do.
Steps to Reproduce
1.Create a Wrap widget.
2.Add a Column or Container as its direct child.
3.Use Generate Dynamic Children on the Wrap using any list.
4.Assign a unique Value Key to the child widget (e.g., Item ID).
5.Run the app.
6.App crashes with Duplicate Keys error pointing to a generic FlutterFlow auto-generated widget name.
Reproducible from Blank
Bug Report Code (Required)
IT4KlcrluJdPm9tK17r+avlF9Cg4QzsnbIJFlutTeA83GKnkG7l3V877QFVUOcvnTXw3PmejhnwX/Mr3vuLtMuw4KSqBbqpz+pZhWDrMezm7Rr6OEpS3b3QnAd1QJhGC5p2JnhEnIu9iSiFiwU6MevK8cBLvH4z7IFgdG+aoXdeK2SrDX1iXc2URm05KZDPz
Visual documentation
Environment
Additional Information
No response