fix(communities): suppress retriable load errors

[tomcasaburi]

Summary

• suppress community-store error scheduling for pkc-js errors marked details.retriableError === true
• keep non-retriable community errors visible after the existing grace delay
• add regression coverage for retriable and non-retriable community error events

Verification

• yarn prettier
• yarn test
• yarn build
• git diff --check
• yarn test:coverage:hooks-stores ran all tests successfully; the strict coverage verifier still exits nonzero on existing unrelated hook/store coverage gaps. The touched src/stores/communities/communities-store.ts reports 100% statements/branches/functions/lines.

---

Note

Low Risk
Scoped to community error scheduling in the Zustand store with regression tests; no auth, payments, or API contract changes.

Overview
Community load errors from pkc-js that set details.retriableError === true are no longer queued into the communities store’s delayed error list, so transient fetch failures should not surface in UI error state after the grace period.

Non-retriable errors still use the existing 1s grace delay and accumulate per community. The delayed callback now bails out if its timeout was already removed from the pending list (e.g. after a successful update clears pending timers), avoiding stale errors being written back.

Tests cover retriable suppression, non-retriable batching, and cleared-pending timeout behavior.

^{Reviewed by Cursor Bugbot for commit 04ae6f2. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Improved error handling to filter retriable errors from the error state, ensuring only critical errors are displayed and reducing clutter in the error list.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds retriable error filtering to the communities store. A new isRetriableCommunityLoadError() helper detects errors marked with details.retriableError: true, and scheduleCommunityError() now early-returns to exclude these from the error state. Two new test cases verify both the exclusion of retriable errors and the correct handling of non-retriable errors with timer-based deferral.

Changes

Retriable Error Filtering

Layer / File(s)	Summary
Retriable error filter implementation src/stores/communities/communities-store.ts	isRetriableCommunityLoadError(error) helper detects retriable errors, and scheduleCommunityError() early-returns without scheduling or storing errors when details.retriableError === true.
Retriable error filtering tests src/stores/communities/communities-store.test.ts	Two test cases verify that retriable errors are excluded from the errors state and that non-retriable errors remain correctly deferred and appended across timer windows.

🎯 2 (Simple) | ⏱️ ~10 minutes

A rabbit hops through error streams,
Filtering retriable dreams,
Some errors rest, some make the store—
The tests now prove what's worth exploring more! 🐰

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title 'fix(communities): suppress retriable load errors' clearly summarizes the main change: adding logic to suppress/skip scheduling of retriable errors in the communities store.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

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

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/suppress-retriable-community-errors

---

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]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/stores/communities/communities-store.ts`:
- Around line 142-146: The callback that cleans up pendingCommunityErrorTimers
assumes pendingCommunityErrorTimers[communityKey] still exists and can crash or
re-add a stale error if clearPendingCommunityErrors removed it first; update the
callback in the cleanup path to first guard that the key exists (e.g., if
(!pendingCommunityErrorTimers[communityKey]) return) before calling .filter and
checking length, and only proceed to delete the key if the array exists and
becomes empty—this ensures clearPendingCommunityErrors can safely remove the
entry and prevents the timeout callback from throwing or re-appending stale
errors when it runs later.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: c99f2bff-5862-44e3-8b81-2565440c2090

📥 Commits

Reviewing files that changed from the base of the PR and between 01e495a and d908314.

📒 Files selected for processing (2)

• src/stores/communities/communities-store.test.ts
• src/stores/communities/communities-store.ts

[tomcasaburi]

Addressed the valid CodeRabbit finding in 04ae6f2 by guarding queued community error timer callbacks after their pending entry has already been cleared. Added a regression test for that stale-callback path.

Local verification after the review fix:

• yarn prettier
• focused communities-store test
• focused coverage rerun for the flaky replies test
• yarn test
• yarn build
• git diff --check
• yarn test:coverage:hooks-stores completed all tests on rerun; it still exits nonzero on existing unrelated baseline hook/store coverage gaps, while the changed communities store reports 100% coverage.