-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have FluxFlatMapUsage
better handle nested Publisher
s
#224
Conversation
error-prone-contrib/src/main/java/tech/picnic/errorprone/bugpatterns/FluxFlatMapUsage.java
Outdated
Show resolved
Hide resolved
07c7915
to
dcd5811
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tnx for this! Indeed important that for GroupedFlux
we don't default to suggesting concatMap
. Left some thoughts :)
if (NestedTypesUtils.isSameTypeNested(FLUX, tree, state)) { | ||
return buildDescription(tree) | ||
.addFix(maxConcurrencyFix) | ||
.setMessage( | ||
"`Flux#flatMap` and `Flux#flatMapSequential` have subtle semantics;" | ||
+ " please explicitly specify the desired amount of concurrency") | ||
.build(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this rule applies to any nested Publisher
, or just when GroupedFlux
is the outer type. If the idea is that users will generally want to deal with a Flux<Publisher>
by performing parallel subscriptions, then generalizing to the former might be nicer. Not sure.
^ In either case we shouldn't reuse NestedTypesUtils.isSameTypeNested
, but IMHO that's not a bad thing; I suspect that a more general matcher for types of T<A, B, C, ...>
may be more useful. (But perhaps that's out of scope for this PR 😄.)
"`Flux#flatMap` and `Flux#flatMapSequential` have subtle semantics;" | ||
+ " please explicitly specify the desired amount of concurrency") | ||
.build(); | ||
} | ||
|
||
return buildDescription(tree) | ||
.addFix(SuggestedFixes.renameMethodInvocation(tree, "concatMap", state)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than omitting this fix, how about we make it the second fix? That would simplify the code and allow us to make fewer assumptions. (In this case patching will rewrite the code to use the bounded-concurrency flatMap
, as desired.)
(In this case we wouldn't need a custom message above.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ I'll push a proposal for this. Of course still open to discuss the alternative!
@@ -33,6 +33,10 @@ void identification() { | |||
" Flux.just(1).flatMapSequential(Flux::just);", | |||
" // BUG: Diagnostic contains:", | |||
" Flux.just(1).<String>flatMapSequential(i -> Flux.just(String.valueOf(i)));", | |||
" // BUG: Diagnostic contains:", | |||
" Flux.just(\"test_1\", \"test\").groupBy(String::length).flatMap(Flux::just);", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
" Flux.just(\"test_1\", \"test\").groupBy(String::length).flatMap(Flux::just);", | |
" Flux.just(1, 2).groupBy(i -> i).flatMap(Flux::just);", |
The other tests are using int
s so I suggest to do the same here :).
import com.sun.tools.javac.util.List; | ||
|
||
/** Utility class that can be used to identify nesting of the same type. */ | ||
public final class NestedTypesUtils { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't really use Utils
as suffix for Util classes, so pushing something.
Final name TBD, maybe we can generalize this 👀.
0016ccf
to
9b4006b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rebased and added a commit with a proposal. Note that most of the changes are also part of #234; the idea is to merge that PR first.
" void m() {", | ||
" Flux.just(1).concatMap(Flux::just);", | ||
" Flux.just(1).concatMap(Flux::just);", | ||
" Flux.just(1, 2).groupBy(i -> i).flatMap(Flux::just, MAX_CONCURRENCY);", | ||
" Flux.just(1, 2).groupBy(i -> i).flatMapSequential(Flux::just, MAX_CONCURRENCY);", | ||
" }", | ||
"}") | ||
.doTest(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.doTest(); | |
.doTest(TEXT_MATCH); |
@rickie this is another one of those things for which we should introduce a check.
"`Flux#flatMap` and `Flux#flatMapSequential` have subtle semantics;" | ||
+ " please explicitly specify the desired amount of concurrency") | ||
.build(); | ||
} | ||
|
||
return buildDescription(tree) | ||
.addFix(SuggestedFixes.renameMethodInvocation(tree, "concatMap", state)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ I'll push a proposal for this. Of course still open to discuss the alternative!
/** Utility class that can be used to identify nesting of the same type. */ | ||
public final class NestedTypes { | ||
private NestedTypes() {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach seems rather niche, as more complex types wouldn't be supported. I think I found another approach. Will push a proposal to this PR, but since it's quite some code, the idea is that we'll merge those changes in a separate PR first, then rebase this PR.
NB: We should get into the habit of writing tests also for these utility classes.
9b4006b
to
6a1085f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I squashed the changes and rebased the PR on top of #234. The original state of the branch was tagged as tmp/eliashenko-PRP-12517-2202-10-15
. No further suggestions from my side; I like this proposal!
Suggested commit message:
Have `FluxFlatMapUsage` better handle nested `Publisher`s (#224)
6a1085f
to
c110c92
Compare
df41c50
to
79ee60b
Compare
c110c92
to
743c5a0
Compare
Rebased and resolved conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice addition. Congrats on your first contribution 🚀 !
Sorry for taking a long time to review the MoreTypes
PR 😬.
FluxFlatMapUsage
better handle nested Publisher
s
Introduce check for calling flatMap() on Flux or Flux