[Feature Request] Add the exchange and mic code attributes back to the subscribe-status event
Closed this issue · 9 comments
Is your feature request related to a problem? Please describe.
Please see the history of this issue here: #70
mic code is no longer included in the subscribe-status event for certain symbol types such as indexes. This introduces an awkward inconsistency in the way that the websocket server works and in the way that subscriptions must be managed.
Describe the solution you’d like
If possible, I’d like the mic code to be added back so that it’s included in the subscribe-status event for all symbol types, including indexes. This would make it possible to confirm websocket subscriptions without the possibility of errors that can result from symbols that are duplicated across exchanges. It would also make the websocket system more consistent, stable, and reliable overall.
Describe alternatives you’ve considered
It was suggested on #70 that indexes should be processed differently than other types of symbols in the low-level websocket connection-handling layer. However, messy logic like this doesn’t belong in low-level protocol code because it makes the code more error-prone, less reliable, less efficient, and less resilient.
Additional context
Exchange and mic code used to be included in the subscribe-status event, as discussed here #61 and here #62, but these attributes were suddenly removed.
Can this be done, or is there a rationale for deciding to treat indexes differently than other types of symbols?
As discussed in #70, the current rationale for excluding mic code from the subscribe-status event isn't very sound, is inconsistent with the way index data is referenced and delivered everywhere else in the Twelvedata system, and introduces problems and unnecessary complexity for processing websocket data and subscriptions.
The role of a data vendor is to organize the price data that they are selling in a clean and consistent way so that customer systems can process the data without confusion or error.
Just for some context and perspective, every other market data vendor in the world, and every other market data websocket server in the world is letting their customers know which exchange an index originates from - because this information is required in order to receive and process the data properly.
Also, if a trader doesn't already know that they can't trade an index, they will easily find out through other ways - and they don't expect a data vendor to tell them this. It's not the role of a data vendor to tell the world anything at all about trading. It's just about delivering the data with the relevant attributes that describe the data.
So, I hope the nature of this request is more clear now. Any thoughts?
As I also mentioned on #70, I've done my best to give some useful information, but I guess you guys just don't care, and it seems you don't care much about the quality of your product.
Pretty disappointing to be completely ignored on what seems to be a pretty important issue. I hoped that you would hold yourselves to a higher standard.
@stephenrs, we appreciate your input. I've passed your request to our product team; however, I'd like to point out that GitHub issues are strictly about this package.
For all product-related questions, please contact Twelve Data support.
Any news or thoughts from your "product team"?
Also, I reported this to Twelve Data support. but after a week of getting nowhere with you there I decided to try here, but I'm getting the same result. No support. No information. No professional courtesy, as most reviews about your company mention.
Is it so hard to treat people with professional courtesy? Is this the way you would like to be treated if you reported an issue or a request to a company?
What's wrong with you?
However, this is not actually a support issue, this is an engineering problem and a flaw in the way you have conceptualized your entire API that affects all packages, and which you don't seem to understand, since I've been trying to help you understand it for almost a year.
@midasSSS do you understand the problem?
Why is this issue closed as completed if the issue has not been resolved and you haven't even shown the courtesy to respond to the engineering issue highlighted in the request?
Simple question: how do you guarantee symbol uniqueness in the Twelvedata API using this package or any other?
You can currently subscribe to symbols using mic_code, guaranteeing uniqueness. Additionally, we will fix inconsistencies with the responses in the upcoming release. Thanks for your patience and contribution!
You can currently subscribe to symbols using
mic_code, guaranteeing uniqueness. Additionally, we will fix inconsistencies with the responses in the upcoming release. Thanks for your patience and contribution!
Thanks for your reply. Is there an expected date for the upcoming release?
You can currently subscribe to symbols using
mic_code, guaranteeing uniqueness. Additionally, we will fix inconsistencies with the responses in the upcoming release. Thanks for your patience and contribution!
Also, for clarity, subscribing to symbols using mic_code doesn't guarantee anything if you can't confirm the subscription using mic_code. This is actually the whole point of this feature request. The chronic inconsistency in the API is the problem being highlighted here.
Do you have any information on when this will be fixed? Some sense of the timeline would be greatly appreciated.
This feature should be added this week.
This feature should be added this week.
That's great news. Thanks for the update and thanks for taking care of this.