A customer is having problems using support multiple media types in Accept header

The API has an endpoint to generate a document and this endpoint can send:

HTTP 200 - media type "application/pdf"
HTTP 500 - media type "application/json"

The API is declared as:

@POST
    @Path("/generate")
    @Consumes({ "application/json" })
    @Produces({ "application/pdf", "application/json" })
    File generateDocument(@Valid DocumentData documentData);

Our customer uses the content negociation based on the header "Accept" and he attempts to receive the header "Accept: application/pdf,application/json" but for now, the header is always filled with "Accept: application/pdf" (the first value in the annotation).

After checking the artifact "org/jboss/resteasy/resteasy-jaxrs/3.15.9.Final-redhat-00001/", it seems the MediaHelper used always returns 1 media type:

"org.jboss.resteasy.util.MediaTypeHelper"
....
public static MediaType getProduces(Class declaring, Method method, MediaType defaultProduces) {
        Produces consume = (Produces)method.getAnnotation(Produces.class);
        if (consume == null) {
            consume = (Produces)declaring.getAnnotation(Produces.class);
        }

        return consume == null ? defaultProduces : MediaType.valueOf(consume.value()[0]);
    }

See the [0] in the method.... Only the first value is taken.

Is this a bug or should only the first value be accepted?

Is it possible to let RestEasy fill the header "Accept" with all values that are inside the annotation @Produces ??

The issue seems to be that RESTEASY-1494 is missing from RESTEasy 3.15. The commit is actually in the branch, but it some how got reverted. It looks like it was there in https://gitlab.cee.redhat.com/resteasy/resteasy/-/commits/3.15/resteasy-jaxrs/src/main/java/org/jboss/resteasy/util/MediaTypeHelper.java with commit. However, the next commit it's gone. GitHub doesn't even show the commit https://github.com/resteasy/resteasy/commits/3.15/resteasy-jaxrs/src/main/java/org/jboss/resteasy/util/MediaTypeHelper.java. I'm not really sure what happened here, but that fix looks like it needs to be applied.