Got null response with 200

davet1

X-Client-Session-Id: 645b1204-0508-11e9-be97-525400a87d41_951

I made a PriceHistory request, for 15 rics, and posted to

https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/ExtractRaw

it responded with a 200 and I extracted the JobId: 0x0683f57ef6004360

I then made a request for that job id:

https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/RawExtractionResults('0x0683f57ef6004360')/$value

But I received a response of http 200, but an empty response body.

I find if I make the request manually now, then I get a body like

@{"@odata.context":"https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#RawExtractionResults/$entity","JobId":"0x0683f57ef6004360"}

but that's no good if my system has already received a null response as if there was something wrong with the request.

Is this expected behaviour? I don't recall seeing it described as a danger in the documentation.

davet1

I think I know why it went wrong.

The first response, despite being HTTP 200 said:

@{"@odata.context":"https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#RawExtractionResults/$entity","JobId":"0x0683f57ef6004360","Notes":["Extraction Services Version 12.3.40157 (ef2d4ecc8c9c), Built Jan  8 2019 20:56:33\r\nProcessing started at 2019-02-08 08:47:40.\r\nUser ID: 9019523\r\nExtraction ID: 2000000063525677\r\nSchedule: 0x0683f57ef6004360 (ID = 0x0000000000000000)\r\nSchedule dispatched via message queue (0x0683f57ef6004360)\r\nSchedule Time: 2019-02-08 08:47:39\r\nInput List (13 items):  (ID = 0x0683f57ef6004360) Created: 2019-02-08 08:47:40 Last Modified: 2019-02-08 08:47:40\r\nReport Template (5 fields): _OnD_0x0683f57ef6004360 (ID = 0x0683f57ef6204360) Created: 2019-02-08 08:47:39 Last Modified: 2019-02-08 08:47:39\r\nERROR: Extraction 0x0683f57ef6004360 failed because: 9019523 has 2 ET2 extractions, limit is 2\r\n"]}

I previously reported this and it was supposed to be fixed in January:

https://community.developers.refinitiv.com/questions/36550/request-limit-seems-to-return-200-not-429.html

Christiaan Meihsl

@davet1, could you please share the body of the original request ? That would help us analyse the issue.

davet1

Body of original request:

@{"ExtractionRequest":{"@odata.type":"#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.PriceHistoryExtractionRequest","ContentFieldNames":["RIC","High Price","Low Price","Universal Close Price","Trade Date"],"IdentifierList":{"@odata.type":"#ThomsonReuters.Dss.Api.Extractions.ExtractionRequests.InstrumentIdentifierList","InstrumentIdentifiers":[{"Identifier":"000030.KS","IdentifierType":"Ric"},{"Identifier":"000120.KS","IdentifierType":"Ric"},{"Identifier":"000150.KS","IdentifierType":"Ric"},{"Identifier":"000210.KS","IdentifierType":"Ric"},{"Identifier":"000230.KS","IdentifierType":"Ric"},{"Identifier":"000240.KS","IdentifierType":"Ric"},{"Identifier":"000270.KS","IdentifierType":"Ric"},{"Identifier":"000640.KS","IdentifierType":"Ric"},{"Identifier":"000660.KS","IdentifierType":"Ric"},{"Identifier":"000670.KS","IdentifierType":"Ric"},{"Identifier":"000880.KS","IdentifierType":"Ric"},{"Identifier":"005380.KS","IdentifierType":"Ric"},{"Identifier":"005740.KS","IdentifierType":"Ric"}]},"Condition":{"AdjustedPrices":true,"QueryStartDate":"1999-02-08T08:47:38.353Z","QueryEndDate":"2019-02-08T08:47:38.353Z"}}}

Christiaan Meihsl

@davet1,

I have just successfully tested your request, in Postman, in the same manner as you describe:

• Sent your request
• Received HTTP status 202
• Pulled the location URL from the response headers
• Ran a GET on the location URL until it returned HTTP status 200
• Pulled the JobId (0x0683f4b5dfd0435b) from the response
• Ran a GET to retrieve the data using the JobId, using this URL:
• https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/RawExtractionResults('0x0683f4b5dfd0435b')/$value
• I received 60305 lines of data, seems ok.

What you observe is not expected behavior.

Note that a bad request would generate an error response with HTTP status 400, but here that is not the case, and I tested your request, it is fine.

Let us try to find the cause ...

• Did you observe this as a once of event, or can you reproduce it regularly ?
• How did you submit your request ? Using Postman, your own code ? Could you eventually share your code ?
• What happens if you manually submit a GET to the following URL ?:
• https://hosted.datascopeapi.reuters.com/RestApi/v1/Extractions/RawExtractionResults('0x0683f57ef6004360')/$value

davet1

https://community.developers.refinitiv.com/discussion/comment/38309#Comment_38309

1. One-off. It's not what I normally see with this particular workflow. But, I haven't made a huge number of requests, so this isn't one in a million.

2. Using my own code. The same code worked on previous requests and subsequent requests. In fact, I twiddled the state of the request in my application to let it reprocess and it received the expected response.

3. It replies appropriately:

@{"@odata.context":"https://hosted.datascopeapi.reuters.com/RestApi/v1/$metadata#RawExtractionResults/$entity","JobId":"0x0683f57ef6004360"}

Christiaan Meihsl

https://community.developers.refinitiv.com/discussion/comment/38310#Comment_38310

@davet1,

3. That is not what it should reply, that call should deliver the data.

I will escalate this to the product support team to investigate what happened, using the Client-Session-Id you gave us, and keep you informed

Christiaan Meihsl

https://community.developers.refinitiv.com/discussion/comment/38318#Comment_38318

@davet1, that looks like the explanation; it is good you found it, and thank you for sharing it.

davet1

https://community.developers.refinitiv.com/discussion/comment/38319#Comment_38319

But this is terrible. Why is it reporting 200? This was supposed to be fixed.

What am I supposed to do? Examine the string in the message because the system doesn't report 429 reliably?

Christiaan Meihsl

https://community.developers.refinitiv.com/discussion/comment/38320#Comment_38320

@davet1,

I have asked the development team for an updated bug fix date.

In the meantime, even if it is not ideal, there are a few possible workarounds:

• Managing requests to ensure that only 1 Price History request is sent at any time.
• Parsing extraction notes to find issues. This is actually a recommended best practice, there is an article on this topic here.