fix(purchasing): stale supplier processes in bill of process dropdown after deletion (#1210)#1213
fix(purchasing): stale supplier processes in bill of process dropdown after deletion (#1210)#1213carbon-agent wants to merge 1 commit into
Conversation
…n bill of process (#1210) Deleting (or creating/editing) a supplier process left stale rows in the bill-of-process supplier dropdown until a hard page refresh. Root cause: `useSupplierProcesses` loaded via `useFetcher`, which fetches once on mount and holds its result. Navigating back to the bill of process reused the stale fetcher data, and the create/edit/delete `clientAction`s only cleared the cache with `setQueryData(key, null)` before the mutation — which the still-mounted fetcher never observed. Fix: - Read through the shared `window.clientCache` QueryClient via TanStack `useQuery` (same key `supplierProcessesQuery(processId)` the clientActions target), so an invalidation reactively refetches the mounted dropdown. `enabled: Boolean(processId)` keeps the disabled-empty-processId guard. - Change the create/edit/delete `clientAction`s to `invalidateQueries` in a `finally` AFTER `serverAction()` commits, so the refetch sees post-mutation data instead of racing the write. Delete scopes to the `processId` from the request URL rather than nuking every supplierProcesses query. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughSupplier process loading now uses TanStack Query, and create, edit, and delete actions invalidate the matching supplier-process cache after server actions complete. ChangesSupplier Process Query Cache
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Problem
Closes #1210. When a supplier process is deleted (or created/edited) and the user navigates back to the bill of process, the deleted supplier still appears in the dropdown until a hard page refresh.
Root cause
useSupplierProcesses(inSupplierProcess.tsx) loaded data with React Router'suseFetcher, which fetches once on mount and then holds its result. Navigating back to the bill of process reused the stale fetcher data. The create/edit/deleteclientActions only cleared the cache withsetQueryData(key, null)before the mutation ran, which the still-mounted fetcher never observed.Fix
SupplierProcess.tsx— read through the sharedwindow.clientCacheQueryClient via TanStackuseQuery, keyed by the samesupplierProcessesQuery(processId)theclientActions target. An invalidation now reactively refetches the mounted dropdown.enabled: Boolean(processId)preserves the existing empty-processIdguard (an empty segment would 404 the API route).$supplierId.processes.{new,$id,delete.$id}.tsx— switch eachclientActionfrom a pre-mutationsetQueryData(key, null)toinvalidateQueriesin afinallyafterserverAction()commits, so the refetch reflects post-mutation data instead of racing the write. The delete route scopes invalidation to theprocessIdfrom the request URL instead of clearing allsupplierProcessesqueries.This follows the repo's established
clientLoader/clientAction+window.clientCacheinvalidation pattern (same key factory as theapi+/purchasing.supplier-processes.$processIdroute'sclientLoader).Acceptance criteria
clientLoader/clientActionVerification
pnpm exec turbo run typecheck --filter=erp— passespnpm exec biome linton the 4 changed files — clean🤖 Generated with Claude Code
Summary by CodeRabbit