Skip to content

Validator reputation/reviewCount updates run outside the quorum transaction #80

Description

@cybermax4200

Why this matters now: Inconsistent reputation data undermines the validator-incentive model the platform is built on.

Problem / What: castVote (validatorService.ts:96-107) increments reviewCount in a separate prisma.user.update before calling resolveQuorumfinalizeProof, which updates validatorReputation inside its own transaction (lines 210-221). If finalizeProof rolls back or throws after reviewCount was incremented, the validator's reviewCount is inflated while reputation is unchanged — permanent drift.

Key Challenges: Moving all reputation accounting into the single finalization transaction (or making it event-sourced), and reconciling any already-drifted rows.

Acceptance Criteria:

  • reviewCount and validatorReputation changes for a vote are atomic with finalization.
  • A fault injected during finalization leaves reputation counters consistent (test).

Relevant files/functions: src/services/validatorService.ts:79-107, 161-245.

Out of scope: Reputation decay/score formula changes.

Labels: advanced, database, bug

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third CampaignadvancedbugSomething isn't workingdatabase

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions