WebClient bodyToFlux(String.class) for string list doesn't separate individual values

[blabadi]

Affects: 5.1.5.RELEASE

Attached demo project for reproducing
bug-demo.zip

spring boot version: spring boot 2.1.3

if I have json response like this : ["v1", "v2", "v3"]
doing:
webclient.get().retrive().bodyToFlux(String.class)

will emit "["v1", "v2","v3"]" as single signal instead of 3 different signals.

---

[sdeleuze]

What happens here is that decoding JSON as String is always handled as low level processing since AbstractJackson2Decoder skips any CharSequence (raw, Mono or Flux) to let StringDecoder handling it. This is on purpose and unlikely to change.

That's said, I am wondering if we could make easier the required steps required to parse Flux<String> with Jackson as expected in this demo project since it seems a pretty reasonable need. Currently, it seems one has to create a new class extending Jackson2JsonDecoder and overriding canDecode to avoid the hardcoded skip for CharSequence which seems making the assumption that there will be a catch-all StringDecoder which is true by default, but not necessarily with custom configurations.

Maybe we could make AbstractJackson2Decoder configurable to allow users to make this skip for CharSequence configurable via a flag. That way it would only require to customize the list of decoders to customize the behavior. The principle seems to be conceptually close to what we do in StringDecoder#allMimeTypes and StringDecoder#textPlainOnly.

Another way to make this more flexible would be to leverage per usage hints but that would require passing hints to canDecode which is currently not the case.

Any thoughts @rstoyanchev @bclozel @poutsma?

[rstoyanchev]

This is stated in the docs.

Note there is already some control. You can decode to List<String> which is exactly what the server is sending. If it needs to be a more continuous Flux then some form of streaming delineation is required anyway. For example if the server sent the strings with new lines, the client would get them one by one.

I am not in favor of adding more options to codecs configuration. That's not necessarily making things simpler.

[fedotxxl]

Holy cow. This is a totally unexpected behavior... Good for you that is documented. Now bug becomes a feature