perf(pb,frontend): cascadeDelete bunk_assignments_draft on scenario delete#994
perf(pb,frontend): cascadeDelete bunk_assignments_draft on scenario delete#994
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 3 minutes and 40 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 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 |
daad911 to
8acf8e1
Compare
63a831c to
e54a286
Compare
8acf8e1 to
1432cb7
Compare
The ScenarioContext exposed a single `loading` flag that went true whenever either the initial React Query fetch or any mutation (create/update/delete/ clear) was pending. ScenarioManagementModal used that flag to swap the scenario cards for a "Loading scenarios..." placeholder, so clicking Delete made the entire list vanish behind the confirmation dialog — leaving only the hardcoded CampMinder card visible. The effect was pronounced because deleting a scenario serially deletes every related draft assignment from the frontend (cascadeDelete=false on bunk_assignments_draft.scenario), so the placeholder window lasts several seconds on real sessions. Split the provider into `isLoading` (initial query fetch) and `isMutating` (any mutation pending), retaining `loading` as the combined flag for backward compatibility. Updated the modal to consume `isLoading` only, so the cards stay in place during delete/clear and the per-row "Deleting..." button state remains the correct in-progress affordance. The slow-delete itself is a separate schema issue tracked for a follow-up PR — switching the relation to cascadeDelete:true will collapse the N+1 serial deletes into a single server-side cascade. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…elete Follow-up to #992. The scenario delete mutation previously fetched every draft assignment for a scenario and deleted them one-by-one from the frontend (N+1 serial HTTP DELETEs) before deleting the scenario itself, because bunk_assignments_draft.scenario had cascadeDelete=false in migration 1500000022. On real sessions this took several seconds and was the visible component of the "list vanishes behind the confirm modal" report — #992 made the list stop vanishing, and this PR makes the delete near-instant. Changes: - New migration 1500000098 flips cascadeDelete to true on bunk_assignments_draft.scenario (relation to saved_scenarios). All other relation properties preserved exactly as created in 1500000022. - useDeleteScenario now issues a single DELETE against saved_scenarios; PocketBase cascades the draft rows server-side. - New test pins the single-call behavior: draft collection is never queried or written during a scenario delete. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
e54a286 to
fa5b9e7
Compare
…am fix Affects pip 26.0.1 install-time handling of files identified as both tar and ZIP. No runtime impact for installed packages; no fixed version released yet. Tracking removal by 2026-05-25. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Follow-up to #992 (scoreboard item #16b). #992 fixed the visible "list vanishes" bug; this PR kills the underlying "long delete" — the several-second serial-delete loop that made the disappearance so noticeable.
Root cause:
bunk_assignments_draft.scenariowas declared withcascadeDelete: falsein migration1500000022, souseDeleteScenariohad to fetch every draft assignment for the scenario and delete them one-by-one from the frontend before deleting the scenario itself. For a real session, that's N+1 round-trips against PocketBase on every delete.Fix: New migration
1500000098flips the relation tocascadeDelete: true(all other properties preserved exactly as in1500000022).useDeleteScenariocollapses to a singlepb.collection('saved_scenarios').delete(id)— PocketBase cascades the draft rows server-side.Base branch
This PR targets
feature/fix-delete-scenario-render(PR #992) rather thanmain. Once #992 merges, I'll retarget this atmainor it'll auto-rebase.Test plan
useDeleteScenarioasserted no calls tobunk_assignments_draft.getFullList/.delete— red against the N+1 loop).downrestorescascadeDelete: falseso a rollback re-requires the frontend loop if paired with an older build.Manual validation (dev/preview)
Scoreboard item covered: #16b — cascadeDelete bunk_assignments_draft (long-delete fix, follow-up to #16)
Requires PR #992 to be merged first, OR testing against the #994 branch directly.
bunk_assignments_draftrows remain (spot-check via PocketBase admin or a query if available).🤖 Generated with Claude Code