docs: revise ADR 0001, risks, and architecture for accuracy

- ADR 0001: distinguish payment/OTP (sync by design) from notifications
  (fire-and-forget); correct misleading claim that notification failures
  surface to clients — they are silently absorbed as FAILED status
- risks.md: upgrade USERNAME_FIELD entry with concrete breakage (admin,
  create_superuser, JWT lookup); add booking overlap race condition with
  root cause and fix (select_for_update)
- architecture.md: document notification/OTP provider coupling as an MVP
  shortcut and note the Phase 2 fix (dedicated NotificationProvider)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
2026-03-01 23:30:04 +03:00
parent aa607b9b6e
commit 229975c612
3 changed files with 20 additions and 4 deletions
+2 -1
View File
@@ -7,10 +7,11 @@ This file tracks known gaps and risks to address in future iterations.
- 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 still `email` while email can be null; verify admin/login flows.
- `USERNAME_FIELD = "email"` while `email` is nullable — concrete impact: Django admin user list shows blank for most customers (phone-only users); `create_superuser` requires email by default; DRF Simple JWT uses email as the lookup field. Fix: change `USERNAME_FIELD` to `"phone_number"` and update `UserManager.create_superuser` accordingly.
## Booking Integrity
- Availability checks and overlap prevention are now enforced for staff bookings.
- **Race condition — booking overlap check is not atomic:** `validate_booking_request` runs the overlap query and returns; the view then calls `serializer.save()` in a separate step with no lock held. Two concurrent POST `/api/bookings/` requests for the same staff slot will both pass validation and both commit. Fix: wrap the overlap check and booking insert in a `select_for_update()` query (or use serializable transaction isolation) so only one request can hold the lock at a time.
- No timezone handling or business hours enforcement.
- No cancellation rules or refund logic.