[19.0][FIX] base_tier_validation: reviewer systray counter drifting (negative) - #52
Open
bosd wants to merge 1 commit into
Open
[19.0][FIX] base_tier_validation: reviewer systray counter drifting (negative)#52bosd wants to merge 1 commit into
bosd wants to merge 1 commit into
Conversation
OCA-git-bot
added
mod:base_tier_validation
Contributor
|
Hi @LoisRForgeFlow, |
bosd
force-pushed
the
19.0-fix-systray-counter-drift
branch
from
June 23, 2026 10:07
7298322 to
ea6f62a
Compare
Contributor
|
@bosd squash commits please 
|
bosd
force-pushed
the
19.0-fix-systray-counter-drift
branch
from
July 23, 2026 13:17
dff0f9f to
b877b4b
Compare
Contributor
Author
|
Done — squashed into a single commit and rebased onto the latest |
The reviewer counter in the systray can display a wrong, even negative, value. The counter was mutated by real-time bus deltas (``review_created`` -> ++, ``review_deleted`` -> --), but ``_update_counter`` sent those deltas to ``self.env.user.partner_id`` -- the *acting* user -- instead of the reviewers whose pending count actually changes. So whenever a user acted on a tier-validated record without being one of its reviewers (creating, editing, force-validating), the wrong user's counter was moved, and an active approver accumulated a drift that eventually went negative. The systray's own absolute count is a ``len()`` and can never be negative; only the blind delta could. Fixes: - JS: the systray component now re-fetches the authoritative absolute count (``review_user_count``) on the bus event, instead of a separate service nudging a +/- delta. The dedicated ``tierReviewService`` (whose only job was that delta) is removed; the component already owns ``fetchSystrayReviewer`` and the ORM via ``useService``, so the badge stays live without drift and can never go below zero. - Python: ``_update_counter`` now notifies the reviewers' partners (the users whose pending count changes), falling back to the acting user only when the reviews are already gone (deletions). The re-fetch is correct but it is not free, and the notification now reaches every reviewer rather than one user. Approving a batch of documents therefore fans out to (reviewers x open tabs x documents) recounts of ``review_user_count``, which is enough to occupy every HTTP worker. The recounts are coalesced so that the fan-out cannot turn into a request storm: - a 15 s leading+trailing debounce around the bus handler -- the leading edge keeps an isolated change instant, the trailing edge settles the final value; - an in-flight guard, so a recount that outlasts the debounce window records that something changed and re-runs once instead of stacking concurrent calls on top of a slow one.
bosd
force-pushed
the
19.0-fix-systray-counter-drift
branch
from
August 27, 2026 12:45
b877b4b to
f2d8ec3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The reviewer systray counter (
tierReviewCounter) can show a wrong — even negative — value (e.g. a user seeing a negative number of reviews "to do").Root cause
The counter is mutated by real-time bus deltas (
review_created→++,review_deleted→--intier_review_service.esm.js). ButTierValidation._update_countersends those deltas toself.env.user.partner_id— the acting user — rather than the reviewers whose pending count actually changes:So whenever someone acts on a tier-validated record without being one of its reviewers (creating it, editing it, force-validating), the wrong user's counter is moved. An active approver accumulates a drift that eventually goes negative. The systray's own absolute count (
res.users.review_user_count→pending_count = len(records)) can never be negative — only the blind delta can.Fix
tier_review_service.esm.js): on the bus event, re-fetch the authoritative absolute count (review_user_count) instead of++/--. This is drift-proof and can never go below zero, regardless of which user receives the event. (ormadded to the service deps.)_update_counter): notify the reviewers' partners (the users whose pending count changes), falling back to the acting user only when the reviews are already gone (deletions), so reviewers get a prompt, correct live update.Version bumped
19.0.1.0.3 → 19.0.1.0.4.Also nticed this behaviour on V118