quarkusio/quarkus · error · IllegalStateException

setting content of MultiByteHttpData is not supported

Error message

setting content of MultiByteHttpData is not supported

What it means

MultiByteHttpData is an internal Netty FileUpload adapter that streams a Multi<Byte> as a multipart file part; its content is fed exclusively by the reactive subscription created in the constructor. setContent(ByteBuf) is one of several InterfaceHttpData lifecycle methods the class deliberately rejects with IllegalStateException because content must only arrive via the Multi pipeline.

Source

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

                    errorHandler.accept(th);
                },
                () -> {
                    done = true;
                    if (paused) {
                        paused = false;
                        resumption.run();
                    }
                });
    }

    void suspend(int awaitedBytes) {
        this.awaitedBytes = awaitedBytes;
        this.paused = true;
    }

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

    @Override
    public void addContent(ByteBuf buffer, boolean last) throws IOException {
        throw new IllegalStateException("adding content to MultiByteHttpData is not supported");
    }

    @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

View on GitHub (pinned to e1c734241f)

Solutions

Do not call setContent on MultiByteHttpData; supply the body as a Multi<Byte> when building the multipart part (QuarkusRestClient multipart API).
If you hold an InterfaceHttpData reference, check its concrete type before mutating and only call setContent on standard MemoryFileUpload/DiskFileUpload instances.
If you need a fully materialized upload, use a File/Path or byte[]-based multipart part instead of the streaming Multi variant.
Update custom encoders (e.g. PausableHttpPostRequestEncoder integrations) to feed data through addContent-free streaming API rather than direct content mutation.

Example fix

// before
fileUpload.setContent(Unpooled.wrappedBuffer(bytes));
// after
MultipartFormItem item = MultipartFormItem.builder()
        .fieldName("file")
        .streamBody(Multi.createFrom().items(bytes)); // content flows via the Multi, never setContent

Defensive patterns

Strategy: validation

Validate before calling

if (data instanceof MultiByteHttpData) {
    throw new IllegalArgumentException("MultiByteHttpData is streaming-only; supply content via Multi<Byte>, not setContent()");
}
data.setContent(buf);

Type guard

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

Try / catch

try {
    data.setContent(buf);
} catch (IllegalStateException e) {
    if (e.getMessage() != null && e.getMessage().contains("not supported")) {
        // rebuild the part with Multi<Byte> content instead of mutating it
    } else {
        throw e;
    }
}

Prevention

Feed multipart streaming parts exclusively through the client's Multi<Byte> API.
Never reuse or mutate a MultiByteHttpData after construction.
Type-check InterfaceHttpData instances before calling mutation methods.
Prefer byte[]/File parts when you don't need reactive streaming.

When it happens

Trigger: Calling setContent(ByteBuf) on a MultiByteHttpData instance, typically from generic Netty HttpPostRequestEncoder/decoder code or custom multipart handling code that treats it like a normal FileUpload.

Common situations: Writing custom multipart encoding logic against Netty's InterfaceHttpData API; reusing a request's multipart parts across encoder implementations; code migrated from standard Netty FileUpload to the RESTEasy Reactive streaming variant.

Related errors

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