If you need to gather all results at the end, the sub-workflow can’t pause in the middle with a Wait node. A Wait turns each item into its own detached execution, so the parent flow can’t truly wait for all of them to finish.
The safest pattern is either to remove the Wait and keep the sub-workflow fully synchronous, so “Wait For Sub-Workflow Completion” works for every item, or to go fully async: store each result in an external place (like a database or table) and use a separate workflow later to collect and consolidate everything.
Damn that sucks since the wait is in a sub-workflow of the sub-workflow and as such the sub-workflow should be “synchronous” since it’s abstracted from the async part.
Would working with webhooks be a workaround in this case?
Using webhooks can work, but only as part of an async pattern, not as a drop-in synchronous workaround. You would trigger the sub-workflow, let it pause on the Wait/webhook, and when each item finishes it would call back (via webhook) into another workflow that stores or aggregates the result.
So the practical options are still the same: either keep the entire called workflow tree free of Wait nodes to stay fully synchronous and get all items back at once, or embrace async with webhooks and an external store and do the final aggregation in a separate consolidation step.
