Fix Event Edit Rental Time Error

Canadian Elite Volleyball Academy — Development Update • April 27, 2026

Fix Event Edit Rental Time Error

What & Why

When a SuperAdmin tries to save edits to an existing event in the Events Management page, the save can fail with a 409 error like "Not enough time remaining. Rental has 60 min available, but this event date needs 120 min." — even when the event itself is unchanged or the rental was already linked to that event before.

The root cause is in the update flow: every event edit deletes and recreates the event's date rows, then re-assigns each new date to its gym rental one-by-one. The rental-capacity validator only excludes the single date row currently being assigned from "already used" minutes, so when an event has two dates that share the same rental (or when validation runs while only some dates have been re-linked), the second call sees the first re-linked date as "other usage" and rejects the save. Because the destructive delete already happened, the event is left in a broken half-saved state.

We need to (a) make the rental-capacity check aware of the full set of dates being assigned to a rental for the same event, and (b) stop performing the destructive delete-and-recreate before we know the new layout will pass validation.

Done looks like

• A SuperAdmin can save edits to an existing event without seeing the false 409 "Not enough time remaining" error when the event's own dates collectively still fit inside the linked rental(s).
• If the event genuinely overflows a rental's capacity (e.g., the new total duration really is longer than the rental's window), the save is rejected before any date rows or rental links are deleted, and the user sees a clear toast naming which date and rental are over capacity.
• After a failed save the event keeps its previous dates and rental links intact (no half-saved state), and the user can adjust and retry.
• A pure metadata edit (e.g., changing only the description, banner, or eligibility) does not get blocked by rental-capacity issues at all.
• Existing single-date and multi-date edits that already work continue to work.

Out of scope

• Changing how rentals are originally booked, parsed from PDFs, or how the available-rentals list is computed.
• The PER_GROUP registration model's groups/dates path (only PER_DATE and WHOLE_EVENT date flows are affected by this bug).
• Redesigning the rental picker UI or its "[This event]" / "[Used in another day]" labelling beyond what's needed for the new error messages.
• Changing the cleanup of staff/attendance/summary references.

Steps

1. Add a server-side pre-flight validator for an event's full date+rental layout. Introduce a single endpoint (or shared helper invoked from the dates POST) that accepts the full proposed list of new dates with their choices for a given event, and returns OK or a structured per-date error. The validator must compute, per rental, the other events' already-linked minutes (i.e., exclude every date that belongs to the event being edited, not just one date id), then sum the proposed new dates' durations against the rental's window.

2. Make the existing capacity check use the same "exclude this whole event" rule so it stays consistent if called directly, and so multi-date events that share a rental aren't double-counted across the per-date assign loop.

3. Reorder the client update flow in so validation happens before destruction. Before calling , call the new pre-flight validator with the proposed dates+rentals. Only proceed with DELETE → POST dates → per-date when validation passes. If validation fails, surface a clear toast that names the offending date and rental and abort the mutation with the event left untouched.

4. Skip the destructive dates rewrite when nothing about the dates or rental links actually changed. Compare the submitted (date, start time, end time, location, gymRentalId, per-date maxSpots where applicable) against the originally loaded values for the event being edited; if they match, do the PATCH only and skip the DELETE/POST/assign loop entirely. This protects pure metadata edits from rental-capacity regressions.

5. Tighten the per-date loop's failure handling. Even with pre-flight validation in place, if a later call still fails, surface the specific date and rental in the toast (rather than the raw 409 body) so the admin knows what to fix. Pre-flight should make this rare, but the message should still be friendly.

Relevant files

- - - - - - - - -

Canadian Elite Volleyball Academy
elitevolleyball.training