Problem
If a node already has its Flow In / Flow Out ports connected and you then add that node to a ForEach Group or a For Group, the group doesn't get Flow In / Flow Out ports for those connections. It gets ordinary data ports instead, so the execution wiring shows up on the group as regular input/output pins.
Origin
Reported by Jason Schleifer.
Impact
The loop's control flow is visibly wrong after grouping. The user has to notice it, delete the bad ports, and re-wire the group's real Flow In / Flow Out by hand.
Repro / evidence
- Build a control chain:
Upstream → Middle → Downstream, connected Flow Out to Flow In.
- Add
Middle to a ForEach Group (or For Group).
- Look at the ports the group grew for those two connections.
In a unit test that does exactly this, the group ends up with two new parameters:
exec_out_1 type=parametercontroltype modes=[INPUT, OUTPUT, PROPERTY] class=Parameter
exec_out_2 type=parametercontroltype modes=[INPUT, OUTPUT, PROPERTY] class=Parameter
and these connections:
Middle.exec_out -> Group.exec_out_1
Group.exec_out_1 -> Downstream.exec_in
Upstream.exec_out -> Group.exec_out_2
Group.exec_out_2 -> Middle.exec_in
Three things are wrong there. The new ports are plain Parameters, not the ControlParameterInput / ControlParameterOutput that make a port render as Flow In / Flow Out. Each one allows input, output and property at once, so a single port acts as both sides of the connection. And the incoming connection from Upstream lands on a port named after the upstream node's output (exec_out_2) rather than an input port, because the boundary port is named from whichever parameter it was copied from.
The group's own real control ports (exec_in, on_each, exec_out, loop_complete, skip_iteration, break_loop) are untouched and still correct — this is only about the ports created for the connections that used to cross the boundary.
Possible direction
_create_proxy_parameter_for_connection in src/griptape_nodes/exe_types/node_groups/subflow_node_group.py rebuilds the boundary port with an AddParameterToNodeRequest that passes only input_types / output_type plus mode_allowed_input=True, mode_allowed_output=True. It never passes the source parameter's type, and on_add_parameter_to_node_request only ever constructs a plain Parameter — so a control parameter can't survive that round trip as a control port no matter what it started as.
Worth deciding first whether an execution connection into or out of a grouped node should get a boundary port at all, or whether it should be re-pointed at the group's existing Flow In / Flow Out.
Problem
If a node already has its Flow In / Flow Out ports connected and you then add that node to a ForEach Group or a For Group, the group doesn't get Flow In / Flow Out ports for those connections. It gets ordinary data ports instead, so the execution wiring shows up on the group as regular input/output pins.
Origin
Reported by Jason Schleifer.
Impact
The loop's control flow is visibly wrong after grouping. The user has to notice it, delete the bad ports, and re-wire the group's real Flow In / Flow Out by hand.
Repro / evidence
Upstream→Middle→Downstream, connected Flow Out to Flow In.Middleto a ForEach Group (or For Group).In a unit test that does exactly this, the group ends up with two new parameters:
and these connections:
Three things are wrong there. The new ports are plain
Parameters, not theControlParameterInput/ControlParameterOutputthat make a port render as Flow In / Flow Out. Each one allows input, output and property at once, so a single port acts as both sides of the connection. And the incoming connection fromUpstreamlands on a port named after the upstream node's output (exec_out_2) rather than an input port, because the boundary port is named from whichever parameter it was copied from.The group's own real control ports (
exec_in,on_each,exec_out,loop_complete,skip_iteration,break_loop) are untouched and still correct — this is only about the ports created for the connections that used to cross the boundary.Possible direction
_create_proxy_parameter_for_connectioninsrc/griptape_nodes/exe_types/node_groups/subflow_node_group.pyrebuilds the boundary port with anAddParameterToNodeRequestthat passes onlyinput_types/output_typeplusmode_allowed_input=True, mode_allowed_output=True. It never passes the source parameter'stype, andon_add_parameter_to_node_requestonly ever constructs a plainParameter— so a control parameter can't survive that round trip as a control port no matter what it started as.Worth deciding first whether an execution connection into or out of a grouped node should get a boundary port at all, or whether it should be re-pointed at the group's existing Flow In / Flow Out.