Loothing

Fixed

• Chat frame no longer fills with red SendAddonMessage failed — result=9 (GeneralError) errors during raid changes. When a raid member went offline, left, or the raid disbanded, the addon's queued messages would log a loud error for every dropped message. These transient races (server begins teardown faster than the client can update IsInRaid()) are not actionable, so they're now logged at debug level instead. The same downgrade applies to whispered targets that go offline. The behavior of the addon is unchanged — only the noise.
• Mixed-version raids now stay in sync. When a v2.0.42 master looter receives a vote or response from a v2.0.40 raider (whose addon still whispers directly to ML), the master looter now re-broadcasts a candidate or voter update so v2.0.41+ council members who never saw the original whisper see the same state. Without this, mixed-version raids could show different vote totals on different screens until the final results landed.
• Master looter's own gear updates now show on their own council table. When the master looter responded to a request for their own equipped gear (rare but possible when ML is also a candidate), the broadcast didn't loop back, leaving the ML's own copy of that candidate's gear blank. Local apply now mirrors the broadcast.
• Vote-policy settings (Multi-Vote, Self-Vote) are now respected by every council member, not just the master looter. Previously, when a council member submitted a vote that violated one of these policies, the master looter would silently filter it out — but other council members would briefly show the vote as counted until the final results overwrote them. Every client now applies the same filter using the master looter's broadcast settings.
• Response-count completion checks no longer trip on duplicate responses. When the response poll resent an already-counted response (e.g., after the original made it through but the master looter hadn't seen it yet, or after an encounter restriction lifted), the master looter previously double-counted it. This could mark voting "complete" while real responders were still missing.
• Council members appearing as "UNKNOWN" class no longer get stuck. When a candidate was created from a voted-for-target lookup before the target's own response arrived (so the class wasn't known yet), later updates with the real class wouldn't take. The candidate row stayed uncolored. Class is now upgraded on every update once a real value is available.
• Roll values stay consistent across council members for legacy responders. When a v2.0.40 client responds without a roll and the master looter generates a fallback random roll for them, that roll is now broadcast to council so sort order and tiebreaks match what the master looter sees.
• Response poll no longer chases players who left the raid. When a player left mid-vote, the response poll kept listing them as missing. The poll now intersects against the responder set captured when voting started, so departed players are dropped from the missing list.
• Response poll resends now run even during master-looter handover. The resend path used to require a known master looter, blocking recovery during the brief window when MLDB had been cleared but the new master looter hadn't been adopted yet. Resends now go ahead since they broadcast and don't need a target.
• First vote on a brand-new item now updates the council UI immediately. When the very first vote arrived before any response had been recorded for an item (so the candidate manager hadn't been lazy-created yet), the local vote was recorded but the voter list update silently no-op'd. Lazy creation now runs so the UI refreshes on the first vote.
• Vote retraction now passes the right shape to UI subscribers. The "candidate updated" event fired by a retraction used to pass a placeholder name-only table; subscribers that expected a real candidate object would have null-pointer'd. Now the actual candidate (when known) is passed.

Hardened

• ALERT-priority addon broadcasts now respect the message-token bucket. ALERT was bypassing both the byte budget and the message-count budget, allowing up to 100 alert messages per second from a single client — well above WoW's hard channel throttle (~10 burst, then 1/sec). Under broadcast load (council voting in active raids), this provoked WoW-side AddonMessageThrottle re-queue storms that fed back into queue depth. ALERT now bypasses only the byte budget and still costs one message token; the per-tick cap drops from 8 to 3.
• Gear-info responses no longer get silently dropped during boss restrictions. PLAYER_INFO_RESPONSE joined the broadcast model in 2.0.41, which made every receiver authoritative for that gear data — but it wasn't on the critical-message replay list, so encounter restrictions silently dropped it. Now queued and replayed when restrictions lift, like the rest of the session traffic.
• Removed dead BroadcastCandidateUpdate helper from the comm wrapper. The function had no callers after the 2.0.41 broadcast conversion. The CANDIDATE_UPDATE and VOTE_UPDATE wire codes and their receivers are retained for mixed-version compatibility with older masters.