Thanks for the detailed clarification. So unless the front ends change their code to fix the issue, the best that curators can do is check a block explorer to make sure the vote was recorded and then to not re-vote?
You are viewing a single comment's thread from:
For the time being there seems to be no other way. If you are sending your votes through the script, you could add calls to
transaction_status_apito wait in a loop at least until your vote becomes part of some block. According to my sources (@gtg to be specific), that API is too sparsely used, even though it is an old API designed specifically for that purpose.But exerting pressure on front-end devs (f.e. by filing an issue) might bear fruits in the future - without it how would they know some improvements are needed :o)
I haven't seen any Hive documentation to describe these parts of the system to developers and so it isn't surprising that front ends don't work in the optimal way. There is clearly a need for some kind of global reporting mechanism for Hive to make sure that developers are all up to speed with best practice.
There is some documentation here, although I'm not sure how up to date it is.
Currently there will probably be more pressure to drop old APIs with HAF approach which kind of allows everyone to build their own customized API, however in case of front-ends it is actually beneficial to have something common like Hivemind (less repeated work and also ability for users to switch to different server in case the one they are using has difficulties). Current Hivemind APIs have many problems though, especially with efficiency, so it might finally be the time to design something new from scratch.
Thank you for explaining @andablackwindow.