Logging a client error which was reported, but which I am also able to replicate internally; Normally Error code 400 is associated with the server timing out,, but this consistently seems to be happening anytime I bring in an options RIC - ;examples...
If I bring in any other chain RIC; like 0#.SPX it works fine, but the options chain universe RICs seem to time out. Any thoughts/ideas? Is this a known issue?
ek.get_data('0#SPXW*.U ', 'DSPLY_NAME')
The Eikon support team has investigate this issue. The team is working on the fix of this issue.
The root cause is following:
The chain RIC's on the request contains 10k+ RICs and if we request single items with DSPLY_NAME it's over 10k RICs.For me it looks that the number of RIC codes we are requesting is too large reason we are getting that error message.I suspect that the issue may be due to the amount of data that we are trying to retrieve.This is indeed backend timeout issue. The reason why it's reproduced with options chains and not with index chains is likely that the options chains mentioned are longer.
I am still experiencing the issue, but only with certain options chain RICs, which makes me think it maybe it has to do something with the universe size...??
For example ;
ek.get_data(["0#MSFT*.U"],['CF_NAME']) works fine. No errors. , and I can run it again and again and have zero problems. All values are returned as expected.
But when I run ek.get_data(["0#SPXW*.U"],['CF_NAME']) I consistently get "ERROR: pyeikon: Backend error. 400 Bad Request"
Why? this is exactly the same formula, just a different RIC....
The client at UBS is also experiencing the same problem: "
We see these EikonErrors on a different set of names today.
For 0#SPXW*.U and 0#SPY*.U: Error code 400 | Backend error. 400 Bad Request
For 0#AMZN*.U, 0#APH*.U, 0#TSLA*.U: Error code 408 | Request timeout occured"
Where do we escalate this to? clearly something is going on since both client and I are able to observe the same behavior....
Hello. I'm Kerry Lytle from the Eikon Tech Support Desk. I entered http://www.iajira.amers.ime.reuters.com/browse/DDA-1028 in regards to this issue. We'll see what dev has to say.