No content to map to Object due to end of input

[Nitzan Mass-Ader]

I'm getting the following RestClientException 400 when trying to update an issue via the SDK. My deps:

<dependency>
    <groupId>com.atlassian.jira</groupId>
    <artifactId>jira-rest-java-client-core</artifactId>
    <version>6.0.2</version>
</dependency>

The error response:
[ErrorCollection{status=400, errors={}, errorMessages=[No content to map to Object due to end of input]}]

The request payload (after being formatted by the SDK from the IssueInput object):

{

"fields": {

"summary": "<REDACTED>",

"issuetype": {

"id": "10010"

},

"project": {

"key": "AIT2"

},

"description": "<REDACTED>",

"priority": {

"name": "Medium"

},

"labels": [

"<REDACTED>",

"<REDACTED>"

]

},

"properties": []

}

This problem is only recreated when working against a company-managed project which I do not have admin access, if that helps narrow it down. Team-managed projects work fine.

Things I've tried:

1. Updating the library to version 7.x.x, but this seems to require Java 21 and I am developing for 17.
2. Running the request through postman, seems to work fine with the same Authorization data, URL, params and headers.
3. I tried debugging the error, I have a hunch it's something to do with the response parsing of whatever is returned. As far as the v2 API is concerned, the request should return 204 with no content, but I also tried it with the returnIssue set to true and I get the same response.

Any help will be appreciated as this seems to be either a simple request structure problem for most people, or the question is left unanswered.

[Christos Markoulatos]

hey @Nitzan Mass-Ader 

My suspicion is that error usually means the SDK is trying to parse an empty response, not that your JSON is wrong. Jira often returns 204 No Content for successful updates, and older JRJC versions (like 6.x) expect a body, so Jackson throws “No content to map…” when there’s nothing to read.

Since you already tested in Postman and it works, the request itself is fine. To confirm what’s happening:

1. Check the raw response in Postman

Look at the status code and body:

• If it’s 204 No Content (or Content-Type: application/json with no body), that’s the trigger for JRJC’s exception.
• If it’s 400 with an empty body, same story, the real validation error didn’t make it across.

2. Enable wire logging in JRJC

Turn on HTTP wire logs so you can see:

• The exact status line
• Headers
• Body length

If the server really returned 204 with no body, it’s a client parsing issue. If it returned 400 with no body, the SDK is still choking on “nothing.”

Your update probably succeeded (or failed for a validation reason), but JRJC 6.x doesn’t handle empty responses gracefully.

[Nitzan Mass-Ader]

What you say sounds reasonable, but what does make me scratch my head is that when I call the same method from the SDK but with returnIssue turned to true the response should be 200 with a body, but the error persists. 

[Christos Markoulatos]

@Nitzan Mass-Ader 

Its one of those that will drive you crazy for sure. My though is the following:

Probably the  even in Cloud, sometimes you get empty bodies despite using returnIssue=true.

Could be due to Lack of Browse Projects permission or issue security restrictions in Company managed or API defaults to minimal response when fields are hidden or filtered.

Combine with observed behavior in your case that you tested with returnIssue=true and still got the same parsing error. That smells to me like the parameter was either ignored or the response was empty due to permissions or field visibility.

its certainty a tough one!