TL:DR As others have indicated, it works correctly, just does not show up on the list in PeakD due to limitation of API used.
Full version There are a lot of steps that the vote needs to pass to be recorded and then show up in the front-end. First it needs to reach the block. See this article if you are interested in technical details, but long story short: the transaction is first sent to some node and after it is validated, it becomes part of "the future" for that node (pending transaction). The node broadcasts that transaction further to other nodes.
Here is first moment when something can go wrong - the node might be separated from the rest of the network and transaction won't reach other nodes.
When transaction reaches witness node, when witness produces block, it becomes part of that block.
In case of high traffic transaction might never make it to the block, especially if it has short expiration time, because there are limits of how many transactions can fit in the block. If there is too many, they have to wait for their turn, and in some cases they wait too long.
Once transaction becomes part of block, it is distributed in the network along with the block.
Nodes might disagree about "the present", when there are competing forks. Even if transaction is part of correctly produced block, it might be part of losing fork. If that happens, it is reverted during fork switch and becomes pending again, therefore it might happen that it already expired or will expire before it can become part of another block.
At some point the block that contained the transaction becomes irreversible. It means that majority of witnesses agreed the block was valid. It takes 45 seconds or more now, but is almost instantenous in normal situation with OBI enables (after HF26). At this point you can be sure the transaction became part of "the past" and won't be reverted.
That is the case here. Your vote was properly processed. You can observe the state of
your transaction with use of transaction_status_api.find_transaction (or your wallet should be doing that for you).
Above was "blockchain reality". But front-ends don't use blockchain directly. They use intermediary services, most likely Hivemind. Hivemind uses its own database to store its view of what happened on the blockchain.
Old Hivemind, as opposed to the one based on HAF, does not properly handle forks, therefore it could happen that it has some data on transactions that were reverted. Very rare case but possible nonetheless.
Even if Hivemind database correctly recorded transaction, front-end might still not show it, if it asks for it with wrong API. Hivemind APIs, especially condenser_api that should be removed long ago, carry some legacy problems. One of those problems is frequent lack of support for paging. That is the source of the problem in your case. PeakD apparently uses condenser_api.get_active_votes that has this problem. It can only return up to 1000 votes and
there is no way for front-end to use it to ask for more (there are other APIs that have paging capability though). It is simply "good enough" most of the
time, so front-ends still use it, because they used it in the past and there is no strong push to change it.
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?
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.