Source
Follow-up from review of merged PR #384 (fix: preserve object-valued owner-both reverse retrieves).
Problem
`collectListInputVariables` in `mdl/executor/cmd_microflows_builder_actions.go` decides whether the output of an `Owner=Both` reverse retrieve is consumed as a list. It walks all statements that take a list input — `AggregateListStmt`, `ListOperationStmt`, `LoopStmt` — but misses the two statements that read a list as a target:
- `AddToListStmt.List` — target of `add $item to $list`
- `RemoveFromListStmt.Variable` (or whichever field holds the list reference) — target of `remove $item from $list`
If the output of a reverse retrieve is fed straight into `add`/`remove`, it isn't marked as a list consumer, so the `!outputUsedAsObject` guard in `expandReverseReference` suppresses `AssociationRetrieveSource` and the original bug from #383 reappears for this usage shape.
Expected behavior
`add $X to $Outputs` and `remove $Y from $Outputs` should mark `$Outputs` as a list consumer for the `Owner=Both` reverse retrieve classification.
Proposed fix
Extend `collectListInputVariables` with the missing cases:
```go
case *ast.AddToListStmt:
if s.List != "" {
vars[stripDollar(s.List)] = true
}
case *ast.RemoveFromListStmt:
// Field name as defined in mdl/ast — adjust if different.
if s.List != "" {
vars[stripDollar(s.List)] = true
}
```
Tests
- Add a regression test where a reverse retrieve's output is consumed only by `add to list` and assert `AssociationRetrieveSource` is suppressed.
- Add a regression test for `remove from list`.
Related
Source
Follow-up from review of merged PR #384 (fix: preserve object-valued owner-both reverse retrieves).
Problem
`collectListInputVariables` in `mdl/executor/cmd_microflows_builder_actions.go` decides whether the output of an `Owner=Both` reverse retrieve is consumed as a list. It walks all statements that take a list input — `AggregateListStmt`, `ListOperationStmt`, `LoopStmt` — but misses the two statements that read a list as a target:
If the output of a reverse retrieve is fed straight into `add`/`remove`, it isn't marked as a list consumer, so the `!outputUsedAsObject` guard in `expandReverseReference` suppresses `AssociationRetrieveSource` and the original bug from #383 reappears for this usage shape.
Expected behavior
`add $X to $Outputs` and `remove $Y from $Outputs` should mark `$Outputs` as a list consumer for the `Owner=Both` reverse retrieve classification.
Proposed fix
Extend `collectListInputVariables` with the missing cases:
```go
case *ast.AddToListStmt:
if s.List != "" {
vars[stripDollar(s.List)] = true
}
case *ast.RemoveFromListStmt:
// Field name as defined in mdl/ast — adjust if different.
if s.List != "" {
vars[stripDollar(s.List)] = true
}
```
Tests
Related