Files
Salon/docs/risks.md
T
mohd ef60218c4c fix: make booking overlap check atomic with select_for_update
Wrap the overlap query and Booking.objects.create() in a single
transaction.atomic() block inside BookingCreateSerializer.create().
Lock the StaffProfile row with select_for_update() so concurrent
requests for the same staff slot are serialized at the DB level;
only one writer can hold the lock at a time, eliminating the race
window between validate() and save().

The early check in validate() is kept for fast user feedback in
the common non-concurrent case. The locked re-check in create()
is the correctness guarantee.

On SQLite (dev/tests) FOR UPDATE is silently ignored but writes
are still serialized. PostgreSQL (production) gets row-level locking.

Update docs/risks.md to mark the race condition as fixed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-02 00:27:04 +03:00

1.8 KiB

Risks And Gaps

This file tracks known gaps and risks to address in future iterations.

Security And Auth

  • Phone normalization is KSA-focused and minimal; broaden for multi-country use.
  • OTP protections are basic; add device fingerprinting and IP throttling if needed.
  • Authentica OTP provider is implemented (SMS + WhatsApp via Authentica OTP); Unifonic remains a scaffold.
  • Social login is a placeholder.
  • USERNAME_FIELD is now "phone_number"; REQUIRED_FIELDS = []; create_superuser accepts phone_number. Admin and createsuperuser work correctly for phone-only users.

Booking Integrity

  • Availability checks and overlap prevention are now enforced for staff bookings.
  • Race condition — fixed: BookingCreateSerializer.create() now locks the staff row with select_for_update() inside transaction.atomic() and re-runs the overlap check before inserting. Concurrent requests for the same staff slot are serialized at the DB level. Requires PostgreSQL in production (SQLite ignores FOR UPDATE but still serializes writes).
  • No timezone handling or business hours enforcement.
  • No cancellation rules or refund logic.

Payments

  • Moyasar payment creation, webhook reconciliation, and idempotency are implemented.
  • Moyasar capture and refund are implemented in the gateway; API endpoints for admin-initiated capture/refund can be added when needed.

Data And UX

  • Ratings are not recalculated from reviews.
  • No image upload or storage strategy for photos.
  • Booking lifecycle notifications are implemented; Authentica can deliver SMS when NOTIFICATION_PROVIDER=authentica.
  • Localization foundations are in progress; full Arabic translation coverage and RTL QA are still pending.

Ops And Compliance

  • No audit logs for admin actions.
  • No multi-tenant isolation or data export tooling.
  • No GDPR/PDPL data retention policies defined.