Error code 400 | Backend error. 400 Bad Request for 0#SPXW*.U

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...

0#SPXW*.U

0#SPY*.U

0#TSLA*.U

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')

Find more posts tagged with

python

eikon

workspace

eikon-data-api

refinitiv-dataplatform-eikon

workspace-data-api

Accepted answers

wasin.w

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.

All comments

jason.ramchandani01

Hi @James.Perkins yes we had another issue with that field earlier today and have escalated for investigation. You can try this which does work for me:

dfv, err = ek.get_data('0#SPXW*.U', 'CF_NAME')
dfv

James.Perkins

Thanks Jason, I tried CF_NAME and still getting the same error....

chavalit-jintamalit

Hi @James.Perkins

This is strange, I can successfully make the same API call.

wasin.w

Hello @James.Perkins @chavalit-jintamalit

I have tried to replicate the issue and I can replicate it only once. All requests are working fine now in my environment.

Do you still encounter the problem?

James.Perkins

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....

chavalit-jintamalit

Hi @James.Perkins

I will email you the process I do.

Usually, you will have to create a ticket to helpdesk and ask them to raise the case to Technical support group.

James.Perkins

Thanks Chavalit, have raise in case 08439430 .

kerry.lytle

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.

James.Perkins

thank you. Interestingly if I change the field i get a slightly different error

ek.get_data('0#SPXW*.U','STRIKE_PRC') . But if i try the same request 10 times it actually works once or twice.... so, there is stability issue somewhere here.

ERROR:pyeikon:Request timeout occured

wasin.w

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.

EXPLORE OUR SITES