Read each item result separately
Loop output identifies an item's index and whether it succeeded, with either its output or its error. That lets you match a problem to the original input and review successful results independently. A failed item should not be mistaken for a successful empty result; inspect the per-item status before using the output downstream.
The loop repeats a single step over the supplied collection. Use it when the same operation should be performed independently for many records, files, or messages. It is not a way to create an unlimited background stream: the loop has a maximum item count and a time limit, so large collections should be split into batches.
Choose concurrency and retries carefully
Loops run with concurrency one by default. Raising concurrency can complete a batch sooner, but it also sends more simultaneous work to the next service. Match the setting to that service's rate limits and to whether each item consumes scarce resources or changes shared data.
When some items fail, review their errors and retry only those that are safe to repeat. If a repeated action can create a duplicate, make it idempotent or check whether the first attempt partially succeeded before retrying. This keeps recovery focused and prevents a small number of errors from causing duplicate side effects across the batch.