Repository navigation
fix(ui): don't wipe the current project when a stale fetch rejects - #321
Conversation
The issue-list aggregate load guarded only the first setter in its .catch; the remaining setters ran unconditionally. Opening project A then quickly switching to B, if A's request rejected after B loaded, cleared B's issues/states/labels/cycles/modules and showed an empty page for a valid project. Guard the whole catch body with the cancelled flag. Same one-line guard applied to ProjectsListPage and the two PageHeader loaders. Closes Devlaner#316 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 41 minutes. View limit details
✨ Finishing Touches
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 |
|
@martian56 #316 — on the issue list, a background request rejecting after you'd already switched projects would blank out the project you were looking at (only the first setter was guarded). Guarded the whole catch across the list page and the two other spots with the same pattern. Green, no open comments. Good to merge? |
Keep main's narrower reset (workspace + project) and error log, behind this branch's early return for cancelled requests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Summary
The issue-list aggregate load guarded only the first setter in its
.catch; the rest ran unconditionally. Opening project A then quickly switching to B — if A's request rejected after B had loaded — cleared B's issues/states/labels/cycles/modules and left an empty page for a perfectly valid project.Linked issues
Closes #316
Type of change
fix:)Surface
apps/web/)What changed
IssueListPage: replacedif (!cancelled) setWorkspace(null)(with 8 unguarded setters after it) with an earlyif (cancelled) return;so the whole reset is skipped for a stale request.ProjectsListPageand both loaders inPageHeader, which had the identical partial-guard pattern.Why this approach
The
cancelledflag already exists (flipped in each effect's cleanup); it was just applied to one line instead of the block. Early-returning the entire catch is the smallest correct fix and matches how the.then/.finallyhandlers in the same effects already guard.Test plan
npm run typecheck+npm run lintpassAI assistance
Claude Code (Opus 4.8)— commits carry aCo-Authored-By:trailer