Skip to content

Fix moveProjects leaving the UI and disk state inconsistent when a pr… - #187

Merged
RykoTheDev merged 1 commit into
RykoTheDev:mainfrom
tuberkulez-takt:fix/move-projects-rollback
Sep 22, 2026
Merged

RykoTheDev merged 1 commit into
RykoTheDev:mainfrom
tuberkulez-takt:fix/move-projects-rollback

Conversation

@tuberkulez-takt

Copy link
Copy Markdown
Contributor

Issue (src/hooks/useProjects.ts:98-125): moveProjects performed setData, followed by N x updateProject + reorderProjects without a try/catch block. A failure at any point (e.g., during the second updateProject call or reorderProjects) left the UI in a state inconsistent with the server—some projects had already changed categories on the backend, yet the UI displayed them as if the move had fully succeeded. Related functions like remove, setPinned, and setCategory already followed the catch { await refresh(); throw e } pattern.

Fix

  • A synchronous snapshot of projects ([...projects]) is saved before the optimistic setData call—avoiding an unnecessary api.listProjects() request and following the pattern used in CategoryManagerModal (prevItems/setItems(prevItems)).
  • The entire server-side sequence (for updateProject + reorderProjects) is wrapped in a try/catch block.

…oject update or reorder operation fails midway.

Capture the previous projects state before applying the optimistic update.
Roll back the optimistic UI state when an API operation fails.
Refresh projects from the backend after a failure to restore the actual persisted state.
Re-throw the error so existing error handling can handle the failure.
@RykoTheDev
RykoTheDev merged commit 3d0da3d into RykoTheDev:main Sep 22, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants