twelvedata/twelvedata-python

[Bug] Websocket responses contain the incorrect mic_code

stephenrs opened this issue · 2 comments

stephenrs commented

Describe the bug

For context, my goal is to have a consistent way to talk to the API using a single string/token that maps to each supported Twelvedata instrument that is guaranteed to be the correct unique symbol. I thought the most logical way to achieve this would be to use "[symbol]:[mic_code]", but I've hit some blocks...

  1. The /timeseries endpoint does not accept [symbol]:[mic_code] as a symbol name (only [symbol]:[exchange]). Although not ideal, it's possible to work around this by using the mic_code request parameter, however. So please consider this a feature request and let me know if you'd like it on a separate ticket/issue.

  2. The websocket server provides the incorrect mic_code in the success response in at least some cases, so if you request based on symbol and mic_code, it's not possible to cleanly and accurately consume the success response and take appropriate action.

Overall, it seems to me that the 'exchange' attribute is still being used/expected where it's not safe because of the potential for ambiguity. The API supports 5 exchanges with the name 'BSE' for example, and it's not possible/feasible for an API user to anticipate when duplicates might cause problems. I actually don't really see the point of the exchange attribute in any API use case, beyond it being a bit more human-friendly, but maybe I'm missing something. mic_code will always be safer and more reliable, and it's hard to justify having 2 different ways to refer to exchanges.

To Reproduce
Steps to reproduce the behavior:

  1. Try https://api.twelvedata.com/time_series?symbol=DVN:XCNQ&interval=1day&outputsize=100&apikey=[]

  2. Subscribe to websocket updates like this:

{"action": "subscribe", "params": {"symbols": [{"symbol": "DVN", "mic_code": "XCNQ"}]}}

The response looks like this:

{"event":"subscribe-status","status":"ok","success":[{"symbol":"DVN","exchange":"CSE","mic_code":"CSE","country":"Canada","type":"Common Stock"}],"fails":null}

Please note that the mic_code in the response is 'CSE' and it should be 'XCNQ'. This problem is currently a blocker for my implementation.

Expected behavior

As above, it would be nice if the timeseries endpoint treated mic_code the same way as exchange.

More importantly, the subscribe-status response from the websocket server should include the correct mic_code value.

midasSSS commented

WebSocket was fixed.

stephenrs commented

@midasSSS That's great, thanks.

Unfortunately though, it turns out that including mic_code in the subscribe-status response doesn't provide much benefit if it's not also included in WebSocket price update events which currently look like this:

{"event":"price","symbol":"NSEI","currency":"INR","exchange":"NSE","type":"Index","timestamp":1675751257,"price":17739.7}

So, now you can subscribe based on mic_code, confirm that the subscription was successful based on mic_code, but you can't properly handle new trades/prices using mic_code.

Can this be added easily/quickly?