scenario is: http call → iterator (loops over ~21 items) → http call per item (image gen api) → set variable → array aggregator → one final http post.
aggregator’s supposed to bundle all 21 into one and then the post fires once. instead it’s firing 21 times, like the aggregator isn’t doing anything at all. source module is set right, i’ve checked it like five times now. burned through half my monthly ops just testing this over and over, someone please save me
bro 99% chance you have a filter or router sitting between the iterator and the aggregator somewhere. even if it “looks” fine, the second there’s any branch in that path, make treats it as a separate stream and just flushes the aggregator after every single bundle instead of waiting for all 21.
go check right after your image-gen http call did you add a filter there to skip failed generations or something? that’s almost always it. take it out, handle the failed ones inside an error handler on that same http step instead, then rerun. should aggregate as one bundle after that.
check that first. but separately for a fixed list of 21 items, iterator into aggregator is kind of overkill and fragile honestly. every iterator bundle costs an operation, and if item 14 hits a rate limit or item 9 times out you’re left with half an aggregation and no clean way to resume.
if this list size is stable, you could just use map() to build all your payloads up front before ever iterating, then hit the api with one batched call if it supports that. less stuff that can break, fewer ops burned per run too. worth it even if it takes an hour to rebuild.
found it…… 
there was a filter after the image-gen call dropping failed generations before set variable. pulled it out, moved that check into an error handler instead. aggregator closes clean now, one post fires. fahad’s the actual fix here.
ahsan, you’re right this is way overbuilt for 21 items though redoing it your way next sprint since we’re bleeding operations.