Skip to content

Support foreach (looping) over input arrays to split event #5707

Closed

Description

@architkshk

Is your feature request related to a problem? Please describe.
Currently, Data Prepper lacks a dedicated processor to iterate over array elements and apply transformations to each element individually. This limitation makes it challenging to process array fields efficiently, especially when dealing with nested data structures or when needing to apply consistent transformations across all elements in an array.

For example, when processing log data with arrays of strings or objects, users currently need to create complex workarounds or multiple processors to handle array transformations, which is neither efficient nor maintainable.

It would also be good to split each element into an individual event.

Describe the solution you'd like
Add a new "foreach" processor to Data Prepper that would:

  1. Accept an array field path as input
  2. Allow defining a set of sub-processors to be applied to each element
  3. Support options for:
    • Transforming elements in-place
    • Creating new events for each element (array splitting)
    • Handling null or missing values
    • Controlling parallel processing of elements

Describe alternatives you've considered (Optional)
Can't find any

Additional context

Activity

  1. dlvenable commented on May 20, 2025

    @dlvenable
    Member

    @architkshk , We have a split_events processor. But, it only works for splitting on strings. If this were to split on an array, would it work for you?

  2. dlvenable commented on May 20, 2025

    @dlvenable
    Member

    If you split_event, then you could use the normal processor chain for the processing that you want to do on each part of the array.

  3. architkshk commented on May 20, 2025

    @architkshk
    ContributorAuthor

    Yes, splitting on array should work, if it splits it into multiple events and rest of the processors acting on each one of them (just like a for loop).

  4. besha100 commented on May 28, 2025

    @besha100

    @dlvenable We have multiple cases where this would be useful, so I’m giving this a thumbs up.

  5. zgouda commented on Feb 5, 2026

    @zgouda

    We're encountering this limitation across multiple implementations where we need to transform nested arrays with conditional filtering and object building. Currently we have to implement workarounds, but a foreach/array iteration processor would make these transformations much more maintainable and scalable. Would be great to see this implemented. @dlvenable

  6. srikanthpadakanti commented on Apr 5, 2026

    @srikanthpadakanti
    Collaborator

    Hello @dlvenable Can you please assign this to me. Thanks.

  7. dlvenable commented on Apr 6, 2026

    @dlvenable
    Member

    @srikanthpadakanti , Thank you for your interest in working on this.

    I think one thing we would need to consider is how iterating over an array works with the JSON pointer structure. We have had some aspects in which processors need both the ability to load from the root of an event and from a relative position. There is a good discussion #6609 that would inform any solution to a foreach processor.

  8. srikanthpadakanti commented on Apr 6, 2026

    @srikanthpadakanti
    Collaborator

    @dlvenable Thanks for linking #6609, I went through the discussion there. I understand the JSON pointer context issue is relevant if we build a foreach processor with sub-processors that run inside the array element context.

    But if we extend split_event to support array fields, each element becomes its own independent event and the normal processor chain handles it from there. No parent/child context ambiguity since each split event is a standalone event. Would that be sufficient to close this issue, or you looking for the full foreach with inline sub-processors as well?

  9. dlvenable commented on Apr 7, 2026

    @dlvenable
    Member

    But if we extend split_event to support array fields, each element becomes its own independent event and the normal processor chain handles it from there. No parent/child context ambiguity since each split event is a standalone event. Would that be sufficient to close this issue, or you looking for the full foreach with inline sub-processors as well?

    I think this is a good way to go.

  10. moved this from Unplanned to In review in Data Prepper Tracking Boardon May 6, 2026
  11. added this to the v2.16 milestone on May 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

enhancementNew feature or request

Type

No type

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions