Skip to content

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

Closed

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 resolveQuorum→finalizeProof, 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

  1. greyhe0x commented on Aug 23, 2026

    @greyhe0x
    Contributor

    I'd like to take this.

    I checked src/services/validatorService.ts on current HEAD. castVote still increments reviewCount via a standalone prisma.user.update (around lines 101–103) before resolveQuorum → finalizeProof, which updates validatorReputation inside its own transaction. If finalization rolls back after that increment, reviewCount drifts permanently while reputation does not.

    Plan:

    • Move reviewCount / reputation accounting into the same finalization transaction so both commit or neither does.
    • Add a fault-injection test that a failure during finalization leaves counters consistent.

    please assign this to me if that works.

  2. grantfox-oss commented on Aug 23, 2026

    @grantfox-oss

    🦊 GrantFox — @greyhe0x has been assigned to this issue as part of the Third Campaign campaign!

    Next steps:

    1. Open a Pull Request referencing this issue (e.g., Closes #80)
    2. Your PR will be reviewed by the ecotask-network maintainers

    Good luck! Track your progress on GrantFox.

  3. grantfox-oss commented on Aug 24, 2026

    @grantfox-oss

    🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

    @greyhe0x's PR #95 was approved and merged by @cybermax4200.

    🏆 @greyhe0x: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (48 total points). Track your full progress on GrantFox.

    👏 Great work, @greyhe0x! Keep contributing to ecotask-network.

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