Run Uni on each item in List sequentially

[TheBroach]

Hi!
I'm sorry if this question is similar to a lot of other questions here and on other forums, but of all the answers I've found on the topic I can't grasp how to solve this. (It also doesn't feel like an uncommon scenario, so maybe add/clarify something about it in the official docs?)

I have a String-list of commands I need to send to an API. They need to be sent in order, and I need to wait for each one to get a response before sending the next one. I've been thinking along the lines of Multi.createFrom().iterable(commands).onItem().transformToUniAndConcatenate(this::sendSingleCommand)...
(where public Uni<CommandResult> sendSingleCommand(String command) { ... } )

(The responses/results probably won't undergo anything more than the occasional logging/metric reporting)

But it feels like since this is a straight up "constructed" Multi, it will fire off all commands right away really fast, and all the Unis will be started close to each other, each without waiting for the response of the previous?

Thankful for help! Thanks for a powerful library!

[jponge]

transformToUniAndConcatenate awaits for the Uni to complete before moving on to the next item, so if the returned Uni captures an eventual response then you should observe that each request is sent after the previous completes.

[TheBroach]

Thank you very much for the clarification! It works nicely in my test-project. As for making this easier for the next person wondering about the same thing, should I come with a suggestion for some form of update in the docs/guides?

[cescoffier]

It’s a recurring question. We should document that somewhere. What do you think @jponge?

…

On Fri 5 May 2023 at 09:34, TheBroach ***@***.***> wrote: Thank you very much for the clarification! It works nicely in my test-project. As for making this easier for the next person wondering about the same thing, should I come with a suggestion for some form of update in the docs/guides? — Reply to this email directly, view it on GitHub <#1268 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADCG7NIYWRFYPP2EASE6MDXESUPZANCNFSM6AAAAAAXVP6Q24> . You are receiving this because you are subscribed to this thread.Message ID: <smallrye/smallrye-mutiny/repo-discussions/1268/comments/5813021@ github.com>

[jponge]

Yes On Fri, May 5, 2023 at 10:11 AM Clement Escoffier ***@***.***> wrote:

…

It’s a recurring question. We should document that somewhere. What do you think @jponge? On Fri 5 May 2023 at 09:34, TheBroach ***@***.***> wrote: > Thank you very much for the clarification! It works nicely in my > test-project. As for making this easier for the next person wondering about > the same thing, should I come with a suggestion for some form of update in > the docs/guides? > > — > Reply to this email directly, view it on GitHub > < #1268 (reply in thread) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AADCG7NIYWRFYPP2EASE6MDXESUPZANCNFSM6AAAAAAXVP6Q24 > > . > You are receiving this because you are subscribed to this thread.Message > ID: <smallrye/smallrye-mutiny/repo-discussions/1268/comments/5813021@ > github.com> > — Reply to this email directly, view it on GitHub <#1268 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGK2K7ZSHRZUHNZOEFD4DXESY23ANCNFSM6AAAAAAXVP6Q24> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>