What is your goal?
Array aggregator is not closing the iteration scope
What is the problem & what have you tried?
Hello,
I have a scenario where an Array aggregator is not closing the iteration scope: the module after the aggregator runs once per iteration instead of a single time.
Chain (flat, linear):
HTTP (esearch) → Iterator (BasicFeeder over an array of ~21 items) → HTTP (fal.ai image gen) → Tools "Set variable" (builds a string) → Array aggregator → HTTP (POST to an external API)
Aggregator configuration (verified):
- Source Module = the Iterator
- Group by = empty
- Aggregated fields = the “Set variable” field
Expected: the Array aggregator collapses all ~21 iterations into one bundle, so the final HTTP module runs once.
Actual: the final HTTP module runs 21 times (once per iteration). Both the aggregator and the final HTTP module show 21 operations. The external API therefore receives 21 partial calls instead of 1 complete call.
Troubleshooting already done:
- Verified aggregator Source Module = Iterator, Group by empty.
- Verified the connection Aggregator → final module is correct.
- Deleted and rebuilt the aggregator + final module from scratch twice — same behavior.
- Exported the blueprint, simplified it to a single iterator + single aggregator, and re-imported it as a brand-new scenario — same behavior (final module still runs once per iteration).
This looks anomalous versus the documented behavior (an Array aggregator with a valid Source Module and empty Group by should output a single bundle and let downstream modules run once).
Could you tell me why the aggregator is not closing the iteration scope here, and what is required to make the downstream module run a single time? I can share the scenario ID / blueprint on request.
Thank you,
[Stefano — epigenetica.tv]
Hey Stefano,
So it’s not the iterator that is producing the extra bundles. Search modules don’t usually return arrays, their output is already iterated. So most likely you need to change your source module to the HTTP module before the iterator and the iterator is not needed at all.
Thanks! To be precise about my setup, there are actually two separate things:
1) The PubMed search — you’re right, and I already removed that iterator: esearch returns the id list, and I now feed efetch directly from the first id (idlist[0]), no iterator there. Done.
2) The part that’s still broken is a different loop. An AI step (HTTP request to an LLM) returns a JSON array of ~21 image objects. I Parse JSON, then Iterate that array and call an image-generation API (HTTP) once per image, build a "key":"url" string with a Set variable, then aggregate.
The problem: the Array aggregator over this image iterator does not collapse. The module right after it (an HTTP POST that must run once with all the images) runs once per image (21 times) instead of a single time.
Aggregator config: Source Module = the image Iterator, Group by = empty. I rebuilt the aggregator + downstream module twice from scratch, and I also exported the blueprint, reduced it to a single iterator + single aggregator, and re-imported it as a brand-new scenario — same behavior every time (downstream runs per bundle).
So: with a single Iterator over a real array → HTTP → Array aggregator (Source = that iterator, Group by empty), what makes the downstream module still run per bundle instead of once? What am I missing to force it into a single collapsed bundle?
Happy to share the scenario ID or the blueprint. Thanks!
Can you share some screenshots of how the modules are setup and what the inputs look like?
Two things to check before assuming it is a bug in the platform.
Check the aggregator’s bundle count in the execution log and see if it shows “1 of 1” which would mean it ran once and consumed all 21 bundles. Otherwise, is it running 21 separate times with 1 bundle each? This can mean different things even if the number of operations remains the same.
Do you have an error handler setup in the fal.ai HTTP module or the Set variable module? If there is an error handler on a module within the path of the iterator that is something that could break the aggregator’s scope tracking even when the Source module is set correctly.
If none of these are true it is most likely some kind of bug and worth escalating to Make’s support with your blueprint attached.
Hi Anthony, thanks a lot — I really appreciate you helping me narrow this down.
I went through both of your checks:
- Bundle count. The module right after the Array aggregator (an HTTP request that should run only once) executes 21 separate times — one call per image — rather than a single collapsed run. I confirmed this from the downstream API’s own logs, where I see 21 distinct requests coming in. So the aggregator doesn’t seem to be consuming the 21 bundles into one output.
- Error handlers. There are none. No error handler on the fal.ai HTTP module, none on the Set variable, and none on any module inside the iterator’s path.
To take the scenario itself out of the equation, I also rebuilt a stripped-down version from scratch: a single Iterator over the array returned by the previous module, then an HTTP request, then a Set variable, then the Array aggregator (Source module set to that iterator, Group by empty), with no error handlers anywhere. I imported it as a brand-new scenario, and the behavior is identical — the module after the aggregator still fires once per bundle instead of once total.
Since both of your checks come back negative and a clean rebuild reproduces it, it really looks like a platform-level issue with how the aggregator closes the iterator scope in this case. I’m going to escalate to Make support with a sanitized blueprint.
I’ll be straight about where we are: this pipeline is business-critical and can’t stay stalled, so if it does turn out to be a bug we’ll need Make to fix it — otherwise we’ll have to move this particular workflow to another platform, which I’d honestly rather avoid. So any further pointers are very welcome. Thanks again for taking the time.
Hi Stoyan, thanks for jumping in, I really appreciate it.
I’d genuinely love to share screenshots, but the scenario has a couple of things I can’t put in a public thread: the HTTP modules carry live API keys in their headers, and the flow is part of a business-critical pipeline I’d rather not expose. So to stay on the safe side I’m going to raise this with Make support directly, as a private ticket with a sanitized blueprint attached (keys stripped out).
That said, I don’t want to lose the community’s input, so here’s the exact setup in words:
- HTTP GET to an API that returns a JSON object containing an array of ~21 items.
- Parse JSON on that response, which exposes the array.
- Iterator over that array (a real array from the previous module, not an already-iterated search output).
- Per item: an HTTP POST to an image API, then a Set variable that builds a
"key":"value" string from the item id and the response URL. No error handler on any of these modules.
- Array aggregator, Source module = the iterator above, Group by empty, aggregating the Set variable field.
- A final HTTP POST that should run once with all the aggregated values.
What I observe: the final HTTP module runs 21 times (once per item) instead of a single time. I also rebuilt the whole thing from scratch as a brand-new scenario — single iterator, no error handlers — and it behaves identically.
If that description rings a bell for a known gotcha, I’m all ears; otherwise I’ll take it to support with the sanitized blueprint. Thanks again for taking the time.
Your source module is wrong but without screenshots I can’t tell you which one to set it to. Check which module has 1 in the bubble next to it and which module has 21.
Hello @Stefano_Spiti_AIC, welcome to the community!
If you are using “old” modules, consider switching to new ones handling authorization using built-in feature.
If you are already using them - you should use Authentication type set to API Key and configured according to your API requirements.
With this approach tokens are encrypted and you can not only share scenario but also create backup copies of your scenario and in case of any 3rd party failure - your tokens will remain safe. So if the process is crucial that should be your first thing to do tomorrow 
Getting back to your main problem.
Are you sure that Parse JSON module is necessary? HTTP module can do parsing for you, and it is turned on by default - so it is quite possible you have 21 bundles from HTTP module and you are parsing it once again.
That’s the only case which comes to my mind. Any further investigation unfortunately requires some screenshots of your config.
Have a nice day!
Michal
