quarkusio/quarkus · error · IllegalArgumentException

Attribute bigger than maxSize allowed (wrapped IOException f

Error message

Attribute bigger than maxSize allowed (wrapped IOException from data.checkSize)

What it means

In QuarkusMultipartResponseDataFactory.createAttribute, after building a MemoryAttribute the factory checks its size against maxSize; when the check fails the resulting IOException is wrapped in an IllegalArgumentException. Unlike the static checkHttpDataSize path, this variant preserves the original IOException as the cause for debugging. It exists to cap memory usage when parsing inbound multipart attributes.

Source

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

            List<HttpData> list = getList(response);
            list.add(attribute);
            return attribute;
        }
        if (checkSize) {
            Attribute attribute = new MixedAttribute(name, value, minSize, charset, baseDir, deleteOnExit);
            attribute.setMaxSize(maxSize);
            checkHttpDataSize(attribute);
            List<HttpData> list = getList(response);
            list.add(attribute);
            return attribute;
        }
        try {
            MemoryAttribute attribute = new MemoryAttribute(name, value, charset);
            attribute.setMaxSize(maxSize);
            checkHttpDataSize(attribute);
            return attribute;
        } catch (IOException e) {
            throw new IllegalArgumentException(e);
        }
    }

    // to reuse netty stuff as much as possible, we use FileUpload class to represent the downloaded file
    // the difference between this and the original is that we always use DiskFileUpload
    public FileUpload createFileUpload(HttpClientResponse response, String name, String filename,
            String contentType, String contentTransferEncoding, Charset charset,
            long size) {
        FileUpload fileUpload = new DiskFileUpload(name, filename, contentType,
                contentTransferEncoding, charset, size, baseDir, deleteOnExit);
        fileUpload.setMaxSize(maxSize);
        checkHttpDataSize(fileUpload);
        List<HttpData> list = getList(response);
        list.add(fileUpload);
        return fileUpload;
    }

    public void removeHttpDataFromClean(HttpClientResponse response, InterfaceHttpData data) {

View on GitHub (pinned to e1c734241f)

Solutions

  1. Raise the configured maxSize on the factory / DiskAttribute.setMaxSize before parsing the response
  2. Handle the wrapped cause explicitly: catch IllegalArgumentException and inspect getCause() instanceof IOException to report size limits to users
  3. Switch to disk-backed storage (useDisk) so large attributes spill to files instead of memory

Example fix

// before
try {
    parts = factory.parseResponse(response);
} catch (IllegalArgumentException e) {
    log.error("parse failed", e);
}
// after
try {
    parts = factory.parseResponse(response);
} catch (IllegalArgumentException e) {
    if (e.getCause() instanceof IOException) {
        throw new ResponseTooLargeException("multipart attribute exceeded maxSize", e);
    }
    throw e;
}
Defensive patterns

Strategy: try-catch

Validate before calling

DiskAttribute.setMaxSize(expectedMaxBytes); // before response parsing

Try / catch

try {
    Attribute attr = factory.createAttribute(response, name, value);
} catch (IllegalArgumentException e) {
    Throwable cause = e.getCause();
    if (cause instanceof IOException) {
        throw new ResponseTooLargeException("attribute exceeded maxSize: " + name, e);
    }
    throw e;
}

Prevention

When it happens

Trigger: Calling createAttribute(response, name, value) with a value whose byte length (in the configured charset) exceeds the factory's maxSize, causing MemoryAttribute.setMaxSize/checkSize to throw an IOException that gets wrapped.

Common situations: Server returning very large form fields in a multipart response while the client uses defaults; multi-byte charsets (UTF-8) inflating byte length beyond the expected char count; maxSize configured too small for the API payload.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors


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