[w-le]

Summary

Parking approval emails could be sent repeatedly when a stale booking snapshot was written back after a successful approval.

The Staff API merges incoming extension_data into the persisted booking. Allocation/restore were sending the entire extension_data hash from an older fetch, which could overwrite parking_notified and reset emails_sent. The next sweep then saw the booking as unapproved/wait-listed and sent another approval email.

Manual-allocation staff/booking/changed events also carry a point-in-time snapshot, which may already be stale by the time it is processed.

Changes

• Re-read the persisted booking before processing manual-allocation change events, and use the persisted process_state/notification ledger to decide whether an email is still owed.
• Serialise manual-allocation handling with a mutex so two events cannot both read the pre-send state.
• Stop sending the full extension_data hash from allocate/restore_allocation.
• Patch only allocation-owned metadata (location, parking_group) via booking_extension_data, leaving parking_notified, emails_sent, and other concurrent fields untouched.
• Update the StaffAPI mock to reflect persisted state on re-fetch, including get_booking.
• Add regression coverage for:
  • stale manual-allocation event payloads
  • resource_id/resource_ids event payloads
  • allocation not rewriting the full extension data snapshot

Why this matters

Without this, a stale sweep or stale event could erase a successful approval’s ledger entry, causing the user to receive the same “Parking space approved” email multiple times.

Testing

./harness report drivers/gallagher/parking_approvals_spec.cr
Result:
1 tested, 0 failures, 0 timeouts, 0 without spec
Deployment notes
- Driver-only change; no database migrations or setting changes.
- Publish the updated driver and restart the affected ParkingApprovals modules.