com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON error on QueryRequest that was working just yesterday. Any change?

[Anon Anon]

com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON error on QueryRequest that was working just yesterday. Any change?
 

QueryRequest portfolioRequest = new QueryRequest("PortfolioItem");
        portfolioRequest.setFetch(new Fetch("State,FormattedID,Name,UserStories,DirectChildrenCount,PercentDoneByStoryPlanEstimate,c_SDP"));
        portfolioRequest.setQueryFilter(new QueryFilter("DirectChildrenCount", ">", "0").and(new QueryFilter("State.Name", "!=", "Complete")));
        QueryResponse portfolioQueryResponse = restApi.query(portfolioRequest);

 

[Anon Anon]

Hi Roger,
sorry for the troubles.
I spoke to the dev team that works on Web Services API and so far we did not identify  recent changes that would cause this exception. Unfortunately I cannot replicate it against my subscription data.

1. Please try the same simple java application that I tested to query on PortofilioItems.I used the same query and the same fetch statement(minus the custom field c_SDP) following your code fragment. I woudl like that we start with the identical code available in this github repo (https://github.com/nmusaelian-rally/rally-java-rest-apps/blob/master/GetPI.java).
Please change the authentication part. Currently I have this line:

String apiKey = "_abc123";

that you may replace with either username/password or API Key valid for your user account.
Please replace workspace OID:

String workspaceRef = "/workspace/12345";

No other changes are necessary to run this code against your data.
Does it work?
2a. If it works, please add the custom field c_SDP to the fetch statement.
2b. If it does not work, please modity the code to fetch only ObjectID:

portfolioRequest.setFetch(new Fetch("ObjectID"));

and modify the query to use FormattedID:

portfolioRequest.setQueryFilter(new QueryFilter("FormattedID", "=", "F123"));

Does that work?

3. I am using Java 1.7 and the following versions of jars:


What is different in your environment?

Thank you.
 

[Anon Anon]

HI Nick,

I tried Step 1 and 2b. The result was the same gson error. 
My environment is all the same jar files and Java 1.7. The only thing that would be different is my company proxy that I am going through. I would be able bypass the proxy tonight at home and see if that same error behavior occurs.

[Anon Anon]

Hi Roger,
One more thing that I would like to ask you to verify.

Is it possible that the password of the user whose credentials are being used to run the code expired or has been changed?
Some time ago I had a case where the same error was caused by invalid password. The user did not know that the password was expired because in the UI they used SSO, but in the code they used regular Rally authentication (username/password). I would expect a 401 in  this scenario, but according to the user it was a password issue.

Incidentaly I had another confirmation of this scenario today. Another customer reported the same issue and I asked them to check if the Rally password used for the authentication in the code was expired and this user discovered that his Rally password was indeed expired. This user normally access Rally through SSO without any problems so it was natural to assume that the Rally password was also current when in fact it wasn't.

As a background, since Rally REST toolkit for Java does not support SSO users who normally login to Rally with SSO have to use regular Rally authentication as long as their organization's SSO supports either hybrid mode (allowing both methods) or SSO with exceptions(in which case the user whose credentials are used to run custom code have to be added to the white list).

Thank you.
 

[Anon Anon]

That was it. I set a new password for the user which has the api key and everything is working normal now. I thought that I had read in documentation that with the new api key authentication we wouldn't need to worry about expired passwords anymore.

Thanks!!

[Anon Anon]

Hi Roger.

You are most welcome. I am glad it is working now.

The underlying issue in this case is that API does not return json (otherwise we would see 401 error, which would be helpful). I think it is a defect, we should return a valid json with a helpful error message. I submitted a defect.

API Keys are tied to a user, so when a user's password is expired, or when a user is inacivated (disabled) the same permissions(or the lack of them) is reflected in the key. However it is possible that you have read somewhere that API Key does not expire when the HTTP session expires - which is true. Unlike the security token described here (https://rally1.rallydev.com/slm/doc/webservice/authentication.jsp) (which expires after the HTTP session is over) API Key does not expire, so the users do not have to worry about maintaining the sesison manually via cookies (the browser does it for you, but with a Java code or a curl command, we had to use cookies) otherwise by the time we hit the security endpoint, the session is over, and no update or create requests can be made with the same security token without maintaining the session manually. Fortunately there is no longer any need to use security token in production on rally1.rallydev.com anymore because we have API Key that do not expire between HTTP sessions (sandbox.rallydev.com still requires them for post requests becuase API Keys are not supported in sandbox).