Round mirrored GIVeconomy sync percentages

[ae2079]

Issue

Summary

Round mirrored GIVeconomy boosting percentages to v5 precision before applying them in impact-graph so reverse sync no longer stalls on high-precision payloads. This keeps the v6 -> v5 sync cursor moving when the upstream event feed contains percentages that do not fit v5's numeric(5,2) storage.

Changes

• round incoming mirrored boosting percentages to the configured GIVpower precision before calling setMultipleBoosting
• filter out mirrored boostings that round down to zero so v5 only writes meaningful rows
• extend the reverse sync unit test to cover high-precision mirrored values and the zero-after-rounding case

How to Test

1. Run NODE_ENV=test npx mocha ./src/services/giveconomyPowerSyncService.test.ts.
2. Confirm the test asserts that high-precision mirrored percentages like 18.6789 are written as 18.68 and tiny values like 0.004 are dropped.
3. Deploy the branch to a staging or production-like environment and run the GIVeconomy reverse sync once.
4. Verify the power_sync_cursor row for sourceSystem = 'giveconomy' advances past previously blocked events and new mirrored boosting updates start landing on v5 again.

Made with Cursor

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Boosting percentages for GIVeconomy power sync are now properly rounded to a configurable precision level, improving accuracy in power distribution calculations.

[coderabbitai]

Warning

Rate limit exceeded

@ae2079 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 26 minutes and 55 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 26 minutes and 55 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 54d3448c-6974-4443-af0e-d5fba6cf4aff

📥 Commits

Reviewing files that changed from the base of the PR and between ef7e40d and 62d3442.

📒 Files selected for processing (4)

• src/repositories/causeRepository.test.ts
• src/repositories/causeRepository.ts
• src/resolvers/projectResolver.allProject.test.ts
• src/resolvers/projectResolver.test.ts

Walkthrough

The changes implement percentage normalization for GIVeconomy boosting updates by introducing a roundSyncedPercentage helper function controlled by the GIVPOWER_BOOSTING_PERCENTAGE_PRECISION environment variable. Percentages are rounded before filtering out non-positive values, and test expectations updated accordingly.

Changes

Cohort / File(s)	Summary
Service Implementation src/services/giveconomyPowerSyncService.ts	Added DEFAULT_GIVPOWER_PERCENTAGE_PRECISION constant and roundSyncedPercentage helper function that derives precision from environment variable. Modified applyGiveconomyPowerSyncEvent to round incoming percentages before filtering out zero/negative entries.
Test Updates src/services/giveconomyPowerSyncService.test.ts	Updated test setup to manage GIVPOWER_BOOSTING_PERCENTAGE_PRECISION environment variable and adjusted fixture expectations to reflect rounded percentages (18.6789 → 18.68, 14.754 → 14.75).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• fix giveconomy reverse sync backlog in impact-graph #2308: Modifies the giveconomy power sync path to adjust how incoming boostings are processed, including filtering and percentage handling in the same service function.

Poem

🐰 Precision hops with careful grace,
Each percentage finds its place,
Rounded soft to decimal's kiss,
Zeros filtered—none shall miss,
Boosting values dance in tune! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and accurately summarizes the main change: rounding mirrored GIVeconomy sync percentages before storage, which is the primary objective of the pull request.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch hotfix/round-giveconomy-sync-percentages

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

src/services/giveconomyPowerSyncService.ts (1)

29-39: Consider sharing precision logic with powerBoostingRepository.

src/repositories/powerBoostingRepository.ts already reads GIVPOWER_BOOSTING_PERCENTAGE_PRECISION and defines a formatPercentage helper with the same +p.toFixed(precision) logic. Duplicating it here risks the two layers drifting (e.g., different defaults, or one reading env at module load vs. per-call). Exporting formatPercentage (or a shared util) and reusing it would keep the rounding contract single-sourced.

Also note a subtle behavioral difference: the repository captures PERCENTAGE_PRECISION once at module load, while roundSyncedPercentage re-reads process.env on every call. This is what makes the test’s per-test env assignment work for the service but not for the repository — worth being aware of if you ever need runtime reconfiguration consistently across both.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/services/giveconomyPowerSyncService.ts` around lines 29 - 39,
roundSyncedPercentage duplicates the precision/rounding logic already
implemented in powerBoostingRepository.formatPercentage (and they differ in when
they read process.env), so export and reuse that single implementation instead
of duplicating it: remove roundSyncedPercentage and import formatPercentage from
powerBoostingRepository (or move the logic into a shared util and export it),
then call formatPercentage(percentage) from the service; ensure you preserve the
desired env-read behavior (choose module-load capture or per-call read)
consistently across both modules when consolidating.

src/services/giveconomyPowerSyncService.test.ts (1)

43-119: Good coverage of the rounding + zero-drop cases.

The fixture exercises both high-precision rounding (18.6789 → 18.68, 14.754 → 14.75) and the round-down-to-zero drop (0.004) alongside an explicit 0, and asserts the exact projectIds/percentages passed to setMultipleBoosting. This locks in the behavior described in the PR objectives.

One optional addition: a case where the value rounds up to a non-zero (e.g., 0.006 → 0.01) would explicitly pin down the boundary between "dropped" and "kept", but it’s not required.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/services/giveconomyPowerSyncService.test.ts` around lines 43 - 119, Add
an extra boosting fixture that rounds up from a tiny non-zero value (e.g., add {
projectId: 3000, percentage: 0.006, ... } in the axios stub payload) and update
the assertions for setMultipleBoosting (in the test 'rounds mirrored
percentages...') to expect projectIds to include 3000 and percentages to include
0.01; keep the existing checks that 0.004 and 0 are dropped and that flags
(allowZeroTotal, allowPartialTotal, allowExceedProjectLimit, emitOutboxEvent,
beforeSave) and callCount remain unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/services/giveconomyPowerSyncService.test.ts`:
- Around line 43-119: Add an extra boosting fixture that rounds up from a tiny
non-zero value (e.g., add { projectId: 3000, percentage: 0.006, ... } in the
axios stub payload) and update the assertions for setMultipleBoosting (in the
test 'rounds mirrored percentages...') to expect projectIds to include 3000 and
percentages to include 0.01; keep the existing checks that 0.004 and 0 are
dropped and that flags (allowZeroTotal, allowPartialTotal,
allowExceedProjectLimit, emitOutboxEvent, beforeSave) and callCount remain
unchanged.

In `@src/services/giveconomyPowerSyncService.ts`:
- Around line 29-39: roundSyncedPercentage duplicates the precision/rounding
logic already implemented in powerBoostingRepository.formatPercentage (and they
differ in when they read process.env), so export and reuse that single
implementation instead of duplicating it: remove roundSyncedPercentage and
import formatPercentage from powerBoostingRepository (or move the logic into a
shared util and export it), then call formatPercentage(percentage) from the
service; ensure you preserve the desired env-read behavior (choose module-load
capture or per-call read) consistently across both modules when consolidating.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 0e7bd02b-0ce9-4ebd-86f6-157d9372a061

📥 Commits

Reviewing files that changed from the base of the PR and between d712c3b and ef7e40d.

📒 Files selected for processing (2)

• src/services/giveconomyPowerSyncService.test.ts
• src/services/giveconomyPowerSyncService.ts

[RamRamez]

Thanks @ae2079