Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP 406 Not Acceptable on ExternalTaskApi.getExternalTaskErrorDetails() #75

Open
mattiasgreen opened this issue Apr 19, 2023 · 4 comments

Comments

@mattiasgreen
Copy link

Requests to ExternalTaskApi.getExternalTaskErrorDetails(externalTaskId) fail with HTTP 406 Not Acceptable due to accept header value incorrectly listing only "application/json". Correct value is "application/json, text/plain".

@mattiasgreen
Copy link
Author

Snippet from generated selectHeaderAccept()

    public String selectHeaderAccept(String[] accepts) {
        if (accepts.length == 0) {
            return null;
        }
        for (String accept : accepts) {
            if (isJsonMime(accept)) {
                return accept;
            }
        }
        return StringUtil.join(accepts, ",");
    }

Snippet from generated getExternalTaskErrorDetailsCall()

        final String[] localVarAccepts = {
            "text/plain", "application/json"
        };
        final String localVarAccept = localVarApiClient.selectHeaderAccept(localVarAccepts);

Note that this results in localVarAccept variable value "application/json", instead of "text/plain, application/json"

@mattiasgreen
Copy link
Author

Temporary local workaround is to patch this generated file, either by editing or overriding this method.

      final String[] localVarAccepts = {
            "text/plain", "application/json"
      };
      final String localVarAccept = StringUtil.join(localVarAccepts, ",");

@mattiasgreen
Copy link
Author

Alternatives for permanent fix, top of my head:

  1. Raise issue and PR for OpenAPI Generator for this "special case" with accept headers and "application/json". In my opinion, this is clearly a bug. However, there may be many clients and solutions out there by now relying on this behavior, so it is unlikely this will be fixed upstream.
  2. Figure out how to automatically "patch" this behavior when generating the client. Perhaps by adding/injecting the workaround after generation. Seems hackish, but perhaps doable.
  3. Change Camunda REST API to only return "application/json" for both status 200 and 500. That is, wrap the error details in simple and flat JSON response.
  4. Figure out if Engine REST can disable the accept header check to avoid HTTP 406 and return. Seems like the worst of options, and I'm not clear if OpenAPI-generated client would even accept the response.

@mattiasgreen
Copy link
Author

Found this open issue which is spot on.
"[BUG][Go] Content type selection breaks when multiple content types present"
OpenAPITools/openapi-generator#10340

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant