fix(frontend): reconcile quick-action updates per action, server wins
WHY THIS MATTERS
Two optimistic-update bugs could show the user state the server does not
have:
1. InitialView's edit merge spread the stale local row OVER the server
response ({ ...updated, ...item, ...changes }), so any server-side
normalization of prompt/document_upload never reached the UI until a
full reload.
2. The account Features page rolled back ALL toggles when ANY of its N
PATCHes failed - if 3 of 4 succeeded, the UI showed the opposite of
what the server now stores.
WHAT IS THE RECONCILIATION RULE?
An optimistic update may paint local state first, but when the server
answers, the response is the truth for the fields it covers; on partial
batch failure, keep the fulfilled updates and roll back only the rejected
ones, and say so ("Some quick actions could not be updated. Try again.").
Found by review of PR #309.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E4PXCdenNH5Mqhm5Sre9Zs
| Repository | open-legal-products/mike |
|---|---|
| Author | Amal <mamalanand3@gmail.com> |
| Authored | |
| Committed | |
| Parents | 3a4480f2 |
| Stats | 2 files changed , +32 , -9 |
| Part of | Refactor workflows into defaults, add-ons, and quick actions |
Capture this commit into my fork
Download a Markdown prompt that tells Claude how to port this
exact commit into your working tree. Run it via
claude -p < capture-commit-cd6caeed.md
from inside the repo you want the change in.