- Shipped
- October 18, 2026 at 6:03 PM UTC
- Author
- Kamo
- Commit
- 68ccc05
Since d1a8762 the download body was a StreamingResponseBody inside the method's ResponseEntity<?>. Spring hands a StreamingResponseBody to its streaming handler only when the declared return type names it; as a wildcard body it went to the message converters, none of which writes a lambda, so every download through MVC answered 500 "No converter for ... with preset Content-Type" (found when the Tool Plane's attachment sends fetched a document). The body is now an InputStreamResource over the MinIO object stream, which ResourceHttpMessageConverter copies out in chunks and closes: still never held whole. A MockMvc test pins the bytes through the real MVC stack; it fails on the old code.