Fix like count drift on failed like/unlike mutations#81
Conversation
|
Warning Rate limit exceeded
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 28 minutes and 28 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Closes #78
Summary
This PR fixes the local like-count drift bug in
nostr-like-buttonwhen like or unlike operations fail.Previously, the component used unconditional arithmetic rollback in the catch path. That meant failures could push the displayed count in the wrong direction even when an optimistic mutation had not actually been applied.
This PR replaces that with snapshot-based rollback, clamps displayed counts to non-negative values, and adds a coalesced authoritative resync path after failed mutations.
What changed
Optimistic state helpers
Added a small internal helper module:
src/nostr-like-button/optimistic-state.tsIt provides:
LikeUiStateclampLikeCount()applyOptimisticLike()applyOptimisticUnlike()rollbackOptimisticLikeState()These helpers keep the mutation/rollback behavior explicit and easy to test.
nostr-likerollback and resync behaviorUpdated:
src/nostr-like-button/nostr-like.tsChanges include:
Why this fixes the bug
The previous implementation assumed that rollback arithmetic should always run in the error path:
That is only valid if the optimistic mutation was already applied.
With this PR:
This removes count drift and makes failure handling deterministic.
Tests
Added focused regression tests in:
src/nostr-like-button/__tests__/optimistic-state.test.tsCovered cases:
Verification
Ran:
npm test -- --runnpm run build-storybook