FF AI CLI SDK: custom-widget Action-parameter callbacks written to parameterValues instead of triggerActions → "parameter not set properly" validation failure

[bahubaliVShete]

Environment

FlutterFlow AI CLI / SDK 0.0.36

Summary

When an existing custom widget that exposes Action-type parameters (callbacks) is placed via the DSL — app.existingCustomWidget(...) then instantiated with action chains inside app.editPage(... ensureReplaced ...) — the SDK writes the callback action chains into the placement node's parameterValues (proto field 12). FlutterFlow's compileDslApp validator instead expects custom-widget Action-parameter callbacks in the node's triggerActions (proto field 17), matching what the FlutterFlow visual editor produces.

Result: compileDslApp fails with <Widget> parameter <onX> not set properly for every Action parameter, even though the action chains are otherwise built correctly.

Expected

The SDK writes custom-widget Action-parameter callbacks into node.triggerActions as FFActionTrigger entries (custom-widget-callback trigger type + the parameter identifier).

Actual

They are written into parameterValues under an action sub-field; triggerActions is left without the callback entry → validation rejects.

Proto evidence

• Custom widget placed via the FlutterFlow visual editor (validates) — field 17:
  {"2":{<action>},"3":{"1":10,"2":{<paramIdentifier>}}}
• SDK-built placement of the same kind of widget — field 12:
  {"1":<key>,"2":{"1":{<paramIdentifier>},"7":{"2":{<chain>},"3":{"1":0}}}}

Workaround

An app.raw(...) post-pass that moves each Action-parameter callback from parameterValues into node.triggerActions as an FFActionTrigger.

Impact

Custom widgets with callback parameters — a common pattern (e.g. wrapping flutter_card_swiper to expose onSwipe / onUndo) — cannot be wired through the DSL without raw-proto surgery.