release hotfix: Adapt to MonoSubscriber not fusing by default #53
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In reactor-core, `Operators.MonoSubscriber` has stopped implementing ASYNC fusion as a base. It continues to be compatible with Fuseable publishers but now by default only negotiates `Fuseable.NONE`. Some RxJava adapter classes don't really have a way of propagating the fusion up to RxJava and used to rely on the default ASYNC capability of MonoSubscriber, testing that `requestFusion` would indeed negotiate that. Now that it negotiates NONE, said tests fail. This commit removes the tests and adds a FIXME as a more in depth follow up to this issue (where we can evaluate if it makes sense to keep the publishers Fuseable). Also update to latest 3.4.x core snapshot. See reactor/reactor-core#3245.
simonbasle
suggested changes
Nov 8, 2022
Comment on lines
100
to
110
| // FIXME | ||
| // @Test | ||
| // fun `Single to Mono`() { | ||
| // Single.just(1) | ||
| // .toMono() | ||
| // .test() | ||
| // .expectFusion(Fuseable.ANY, Fuseable.ASYNC) | ||
| // .expectNext(1) | ||
| // .expectComplete() | ||
| // .verify() | ||
| // } |
There was a problem hiding this comment.
the test can be kept around to validate onNext/onComplete are translated, but simply removing the assertion of fusion negotiation:
Suggested change
| // FIXME | |
| // @Test | |
| // fun `Single to Mono`() { | |
| // Single.just(1) | |
| // .toMono() | |
| // .test() | |
| // .expectFusion(Fuseable.ANY, Fuseable.ASYNC) | |
| // .expectNext(1) | |
| // .expectComplete() | |
| // .verify() | |
| // } | |
| @Test | |
| fun `Single to Mono`() { | |
| Single.just(1) | |
| .toMono() | |
| .test() | |
| .expectNext(1) | |
| .expectComplete() | |
| .verify() | |
| } |
Note also that the Fuseable trait removal will be dealt with via the reactor-addons issue.
simonbasle
approved these changes
Nov 8, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In reactor-core,
Operators.MonoSubscriberhas stopped implementing ASYNC fusion as a base. It continues to be compatible with Fuseable publishers but now by default only negotiatesFuseable.NONE.Some RxJava adapter classes don't really have a way of propagating the fusion up to RxJava and used to rely on the default ASYNC capability of MonoSubscriber, testing that
requestFusionwould indeed negotiate that. Now that it negotiates NONE, said tests fail.This commit removes the tests and adds a FIXME as a more in depth follow up to this issue (where we can evaluate if it makes sense to keep the publishers Fuseable).
Also update to latest 3.4.x core snapshot.
See reactor/reactor-core#3245.