?Hi, i have a strage behaviour with /Search/HistoricalCriteriaSearch
In Java and in Postman I make the following request, this is the body (header is also the same):
{"Request":{"RicPattern":"FGBLH6","CurrencyCodes":["978"],"ExpiryDate":{"Start":"2016-03-01T00:00:00.000Z","End":"2016-03-31T00:00:00.000Z"},"Range":{"Start":"2017-02-03T09:06:12.113Z","End":"2017-02-03T09:06:12.115Z"}}}
In Postman I get an http 200 and an empty result. In the Java call I get:
Response Code : 502 / {"error":{"message":"Gateway ETH returned error status code: BadRequest from (http://rp.cp.hdc.reuint.com/TickHistoryWS/search) Error ID: [ca49310a-fdcd-49fc-93f5-3a232e031aba]"}}
Maybe there is something wrong in the request, I'm currently investigating that, but that is not my current questions. My question is: how is it possible to get different behavior between Postman and Java Http calls?
69
●11 ●20 ●19
Different behaviour: Postman / Java Http call
Other previously working tests are now also failing, i therefore investigated a bit deeper. Looks like this type of request is not working if authentication request and search request are performed very close after each other. In debug mode (where there is more time in between) it is working fine.
Can you please confirm if that is the correct reason for this situation and please advice how to handle it on customer/client side?
Just FYI, returned HTTP Status codes are documented here.
502 is a BadGatewayException, meaning that the server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
I do not know if your hypothesis is correct or not, I hope the dev team can clarify this.
My hypothesis is of course just a hypothesis. I was just able to reproduce the behavior in normal (full speed) JUnit test run and not in debug where i was steeping manually. Also i was not able to reproduce this behavior using postman, where the authentication was done early in the morning. That's why I guess there must be some relation between authentication and request. That is the only difference between the JUnit run and the Postman request.
@Philipp, considering your query, we moved it from the DSS to the TRTH forum, it seems more appropriate (HistoricalCriteriaSearch is an API call for users with TRTH permissioning), and will help people discover it. AHS
1.1k
●5 ●3 ●5
I have advanced this case against an open REST API bug. I believe the reason you got the 502 failure was because Currency Code "978" is not a valid code from the Historical Currency list. Note: In the future when the bug is fixed, you will received a 400 reply with a error message saying something about the value provided was invalid.
I am not sure why you would not have received a 502 to all requests that specified that same code. Each response will have an X-Request-Execution-Correlation-Id HTTP header. If you can provide that information per troubled call then I can investigate the specific operations that lead to the undesirable outcome.
You say "Currency Code "978" is not a valid code" but why is this request then working fine in Postman? I really think the issue it the time between authentication and request. That is the only difference between running my test case in normal and in debug mode.
I agree your observation requires some additional thought - I already pondered it a bit the first time, but meant to come back to it to figure out why that might be true. I hope to get to that tomorrow. Are correct values working for you now, or even with correct values do you see trouble?
Thanks for your help. This behavior was always occurring with correct values. That's why I'm so worried about it. I tested always with the same (generally working) request.
If it helps I can try to reproduce the situation today again, just let me know.
