Use awaitSingle operator instead of awaitFirst

[GeorgePap-719]

A minor refactoring to use awaitSingleXxx operators instead of awaitFirstXxx.

Operators awaitFirstXxx are going to be deprecated. Also, awaitFirst operator has no value on Mono types.

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[mp911de]

awaitFirst() is going to be deprecated so we rather need to switch to awaitSingle() methods.

See

https://github.com/Kotlin/kotlinx.coroutines/blob/550cdf6ebf2fe4d226f057fbbf3745fe92c6e722/reactive/kotlinx-coroutines-reactor/src/Mono.kt#L163

Even though the end-result is the same,

In fact, there's (or has been) a subtle change. awaitFirst lets the coroutine continue even when the stream hasn't finished yet. This can lead easily to transactional visibility issues whereas awaitSingle() continues only when the operation has completed.

That being said, we should move to awaitSingle… and friends.

[GeorgePap-719]

Oh ok, mb did't see the were deprecated. Should i open a different mr for using awaitSingle or should i just edit this mr?

This can lead easily to transactional visibility issues

Also, maybe can you point me to a direction to understand a bit better the potential issue? (Although i kinda get the general concept).

[mp911de]

Feel free to force-push your changes against this pull request.

You can find a bug report regarding the problem that arises from too early continuation at spring-projects/spring-framework#25007

[GeorgePap-719]

The usage of package kotlinx.coroutines.reactive.awaitSingle instead of the reactor's is intentional?, if it's not probably i can also change it in this mr.

[mp911de]

It is intentional to stick with Publisher semantics and not with Mono semantics.

[GeorgePap-719]

Ok, then i think the mr is ok from my side (unless you have some pointers ofc).

If i may ask how come we want to stick with Publisher semantics in this case (any directions like above would be welcomed)?

[mp911de]

Some Mono operators send a completion signal on their own upon seeing an element without that the upstream Publisher has sent a completion signal. While that's useful in some cases, for the general flow this creates rather concurrency issues.

[mp911de]

Paging @sdeleuze AwaitKts Publisher<T>.awaitSingleOrNull() is deprecated but it is required for making spring-projects/spring-framework#25007 work. Can you provide guidance?

[GeorgePap-719]

Some Mono operators send a completion signal on their own upon seeing an element without that the upstream Publisher has sent a completion signal.

I guess this applies in cases such as first() ?

[sdeleuze]

@mp911de I am going to ask to Kotlin team.

[sdeleuze]

@mp911de So after discussion it looks like they don't plan to change those deprecations on Publisher side but Mono.awaitSingleOrNull current behavior is wrong and they plan to fix it via Kotlin/kotlinx.coroutines#3487. So once that fixed I think the idea would be to use the Mono extension. I think that would cover spring-projects/spring-framework#25007 use case as well. Do you agree?

[mp911de]

Thanks Sebastien. I fully agree with the bugfix as the linked ticket exactly describes the problem and we're happy to switch to Mono extensions once the issue is fixed.