quarkusio/quarkus · error · IllegalStateException

getting all the contents of a MultiByteHttpData is not…

Error message

getting all the contents of a MultiByteHttpData is not supported

What it means

get() returns the entire part content as a byte[] in standard Netty HttpData. MultiByteHttpData is a streaming adapter whose buffer may not hold all bytes at once and which requests more data lazily from the upstream Multi; materializing the whole content would violate its design, so get() throws IllegalStateException.

Solutions

  1. Read content incrementally via getChunk(int) only after isReady(chunkSize) returns true, as PausableHttpPostRequestEncoder does.
  2. If you need full bytes, send a byte[]-based part instead of a Multi<Byte> streaming part.
  3. Collect the upstream Multi<Byte> itself (e.g. Multi collect().in(byte[])) before sending rather than pulling from the adapter.
  4. Do not write generic code that assumes get() is safe on every FileUpload; branch on the concrete type.

Example fix

// before
byte[] all = multiByteHttpData.get();
// after
ByteBuf chunk = multiByteHttpData.getChunk(BUFFER_SIZE); // after isReady(BUFFER_SIZE)
byte[] part = new byte[chunk.readableBytes()];
chunk.readBytes(part);
Defensive patterns

Strategy: type-guard

Validate before calling

byte[] safeGet(InterfaceHttpData data) {
    if (data instanceof MultiByteHttpData) {
        throw new IllegalArgumentException("Read streaming parts via getChunk(), not get()");
    }
    return data.get();
}

Type guard

boolean supportsFullGet(InterfaceHttpData data) {
    return !(data instanceof MultiByteHttpData);
}

Try / catch

try {
    byte[] all = data.get();
} catch (IllegalStateException e) {
    if (e.getMessage() != null && e.getMessage().contains("not supported")) {
        // drain incrementally via isReady()/getChunk()
    } else {
        throw e;
    }
}

Prevention

When it happens

Trigger: Calling get() on a MultiByteHttpData, e.g. from debugging/logging code, generic InterfaceHttpData processors, or a decoder that drains completed uploads into memory.

Common situations: Inspecting sent multipart bodies in tests or interceptors; post-request processing of response/file-upload structures that call get() uniformly; tools that snapshot multipart parts for retries.

Related errors


AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/540ed6348b4b8264. Report an issue: GitHub.

Appendix: source

Thrown at independent-projects/resteasy-reactive/client/runtime/src/main/java/org/jboss/resteasy/reactive/client/impl/multipart/MultiByteHttpData.java:167

    @Override
    public void setContent(File file) throws IOException {
        throw new IllegalStateException("setting content of MultiByteHttpData is not supported");
    }

    @Override
    public void setContent(InputStream inputStream) throws IOException {
        throw new IllegalStateException("setting content of MultiByteHttpData is not supported");
    }

    @Override
    public void delete() {
        // do nothing
    }

    @Override
    public byte[] get() throws IOException {
        throw new IllegalStateException("getting all the contents of a MultiByteHttpData is not supported");
    }

    @Override
    public ByteBuf getByteBuf() {
        throw new IllegalStateException("getting all the contents of a MultiByteHttpData is not supported");
    }

    /**
     * check if it is possible to read the next chunk of data of a given size
     *
     * @param chunkSize amount of bytes
     * @return true if the requested amount of bytes is ready to be read or the Multi is completed, i.e. there will be
     *         no more bytes to read
     */
    public boolean isReady(int chunkSize) {
        return done || buffer.readableBytes() >= chunkSize;
    }

View on GitHub (pinned to e1c734241f)