Read and parse data from S3 PutRequest using Spring WebFlux - spring

Question

I have a stub setup to handle tests that interact with AWS S3 buckets. The (custom) stub implementation uses Spring WebFlux to respond to e.g. S3 put-requests.
Lately I have been forced to change my S3 implementation to use an InputStream rather than an actual file as input. My problem is now that my stub implementation doesn't yield the expected result when passing an InputStream rather than a file.
My stub is currently implemented like this:
RouterFunction<ServerResponse> putS3Object() {
return RouterFunctions.route(PUT("/S3/MyBucket/{filename}").and(accept(TEXT_PLAIN))) { ServerRequest request ->
return request.bodyToMono(String)
.doOnSuccess { s3Stubs.registerPutObject(request.pathVariable("filename"), it) }
.flatMap { response -> ServerResponse.ok().build() }
}
}
The String passed to s3Stubs.registerPutObject in the it parameter contains the expected value "Hello World".
Now, when I use an InputStream as argument to the S3 API instead of a file the it parameter is no longer "humanly readable". It contains data like: 18;chunk-signature=c27c7fa381b8aa2824e8487979d2d0e9ded04dd3 ..... 0;chunk-signature=db7e8b1bacc57da0d410ee116 - where I would have expected the same result "Hello World".
I'm unsure if this is related to my Webflux implementation or how S3 is handling InputStreams in comparison to actual files.
Using the exact same S3 implementation using InputStream works when putting to a real world S3 bucket...

Answer 1

Looking at the AWS S3 SDK, it seems that the InputStream variant is also requiring some metadata, which should contain the length and base64 hash of the content. This is probably what you're seeing here being sent to your stub.
bodyToMono(String.class) really buffers the whole request body in memory and decode that into a String. For other wire formats, Spring relies on Encoder and Decoder implementations (there's one for JSON, another one for protobuf). It is possible, but quite complex to write your own, and probably not the best choice when writing a stub implementation.
If you want to really stub this, you should either accept whatever the S3 client is sending you, or read up about the actual wire format used by that client.
Now about your current implementation: it seems you're trying to do I/O operations within a doOnXYZ method. Those methods are called "side-effect" methods, since their goal is to print some logs or record some state, but not do I/O-related work - and definitely not blocking I/O. Reactor offers ways to wrap blocking code for that.