Omniplex
Issues have been resolved and vote counts are corrected across all affected bots.
Our team is looking into some ongoing issues with our frontend not displaying the correct vote counts.
Redeeming vote credits (converting a bot, server, or team's earned votes
into shop credits) was implemented in a way that marked the underlying
votes as void once redeemed, the same flag used when votes are wiped
by an automated monthly reset or a staff-initiated reset. Every part of
the platform that counts votes, public totals, approximate_votes,
leaderboards, filters out anything marked void. The result: every time an
owner cashed votes in for credits, those votes silently disappeared from
their bot or server's public vote count too, not just from the pool of
votes still eligible to redeem.
This was a data-correctness bug, not an outage. The flawed logic was first written on July 28, 2026, and stayed live, unnoticed, for roughly five weeks. It only came to light on August 31, 2026, when a bot owner noticed their vote count had dropped after voting and flagged it.
Confirmed by direct inspection of the affected data: 11 individual votes across 2 bots were incorrectly voided between July 28 and August 31. Any bot, server, or team that redeemed vote credits during that window would have seen its public vote count drop by however many votes were redeemed, with no actual vote reset having occurred.
No votes were lost, and nothing about the credits themselves was wrong, the credit math was correct. The only thing affected was the public vote count display: Bot Listings, Server Listings, Pack Listings, and the website generally, wherever a vote count is shown.
The void column on a vote record was overloaded to mean three
different things: an automated monthly reset, a staff-initiated reset,
and (incorrectly) a vote being spent on credits. Every public
vote-counting query filters on void = false, since that's the correct
behavior for the first two cases, so it also silently applied to the
third.
A separate refactor on August 29 (moving the backend's raw SQL over to a type-safe query generator) mechanically carried this same logic forward unchanged. That refactor's own verification compared new and old query output side by side and matched, which is exactly why it didn't catch this: the bug was already baked into the behavior being verified against, not introduced by the refactor itself.
This wasn't caught by any internal monitoring or test suite, the votes and vote-credits package had no test coverage at the time. It was user-reported: a bot owner noticed their vote count drop right after voting and flagged it, which is what triggered the investigation.
Once reported, the fix shipped the same day:
credit_redeem marker now tracks "this vote has already been cashed
in," which still correctly prevents the same vote from being redeemed
twice, without hiding it from the entity's public vote count.All 11 votes and every affected count were confirmed restored before this incident was marked resolved.