Ibrahim Saad

[Ibrahim5aad]

Ibrahim Saad

Overview

All tasks are completed. First three (RE-001, RE-002, RE-003) are done within the stated 3 hours time frame (+ breaks).

• RE#001 Completed
• RE#002 Completed
• RE#003 Completed

The rest of tasks (RE-004, RE-005, RE-006) are done outside that time frame.

• RE#004 Completed
• RE#005 Completed
• RE#006 Completed

Task Report

Commits per task

Task	Commits
RE-001 (Guest Booking)	1502032 feat(api): implement guest room booking with validation
	e143a99 feat(ui): implement booking flow with validation errors and confirmation dialog
RE-002 (Booking Validations)	db6a734 feat(api): guarding against reservation conflicts/overlaps
	04e277c fix(api): concurrent overlapping booking requests
	64c3bb1 fix(api): open create reservation transactions if closed
RE-003 (Staff Login)	84980e1 feat: staff login with JWT auth and reservations view
RE-004 (Check In)	3dcc345 feat: staff can check in guests
RE-005 (CSV Import)	0027eb1 feat: staff room management with CSV import and room listing UI
RE-006 (Housekeeping)	fe0047b feat: add check-out, room state management, and housekeeping

Tasks overview

The commit log is a rough overview of the time spent, some breaks were took between tasks.

- Initial easy wins / refactor

Some initial easy wins that I thought will help lay down some proper foundation for any coming work, mainly exception handling (dont need to care about it afterwards or handle exceptions in larger surface area), logging and proper API error responses. Captured in commits 87c48fb and c668075.

Expected behavior: Exceptions handling responsibility are offloaded from repositories and controllers, centralized in ExceptionHandlingMiddleware for convenience (one place to catch our custom errors, handle, set informative API error responses). Custom erorr hierarchy were added as well.

---

(RE-001) Guest Booking

Around an hour spent in this task. The work is divided between two commits; 1502032 for API-related work, and e143a99 for UI-related work.

Expected behavior: Guests can book their room by selecting a room card, entering their email and date range in a modal, and submitting. The API validates all inputs via FluentValidation (email format with domain, room number format ###, start before end, 1-30 day duration, no past dates) and checks that the room exists. On success, a confirmation dialog shows the reservation details. On failure, validation errors are shown as toast notifications.

---

(RE-002) Booking Validations

Around 30 minutes spent. The work is divided between two commits; db6a734 for the overlap detection query, and 04e277c for handling concurrent booking race conditions. A small follow-up fix in 64c3bb1.

Expected behavior: Double bookings are prevented by checking for overlapping reservations on the same room before inserting. A serializable transaction wraps the multistep booking operation to prevent race conditions from concurrent requests.

---

(RE-003) Staff Login

Around an hour spent in 84980e1,.

Expected behavior: Staff authenticate with a shared access code via a login dialog. The backend validates the code against configuration, issues a JWT token, and the frontend stores it in sessionStorage. Authenticated staff see navigation links to Reservations. The reservations list defaults to showing today and future reservations, with filters for date range, room, and guest email.

---

(RE-004) Check In

Captured in commit 3dcc345.

Expected behavior: Staff can check in a guest for any reservation that covers today. Check-in requires email confirmation matching the reservation. The backend validates that the the reservation is not already checked in, and today falls within the reservation period, and the room is not dirty. On success, the reservation is marked as checked in and the room state is set to Occupied. Both updates are wrapped in a transaction for atomicity.

---

(RE-005) CSV Import

Captured in commit 0027eb1.

Expected behavior: Staff can import rooms via a CSV file (up to 500 rooms) through a drag-and-drop dialog. The import result shows counts of imported and failed rows, with a detailed error table listing line numbers and failure reasons. Valid rooms are atomically inserted within a transaction.

---

(RE-006) Housekeeping

Captured in commit fe0047b.

Expected behavior: Staff can mark rooms as clean or dirty from the Rooms page. Check-out marks the room as dirty. Staff cannot check in a guest to a dirty room (the check-in button is disabled and the backend also enforces this). The Rooms page supports filtering by status (Ready/Occupied/Dirty) and by floor, with pagination.

Notes

Key decisions:

1. Error handling strategy ExceptionHandlingMiddleware + exception/error hierarchy
2. RoomNumber converted to string, semantically it is not a numeric value that we will do arithmetic on.
3. Advertising types and response errors for OpenAPI spec.
4. Scoped DB connections and higher abstractions. Singleton kind of negates the purpose of enabling WAL as connections are serially reentrant for single connection even for readers.
5. Serializable transactions for critical sections like booking (check conflict query + insert reservation query). Concurrent booking will serially wait to avoid conflicts that could happen in scenarios like two overlapping bookings finding at the same time that there is no conflict/overlap after the (check conflict query), then proceed to insert, resulting in a double booking.
6. For simplicity, server local time is used as a source of truth for time. That won't work if the server is deployed in another timezone than the hostel/hotel.
7. For simplicity, I handled JWT expirey using 401/Unauthorized interceptor.

Encountered along the way:

1. CORS configuration in the API project is wrong, UseCors should come before UseMvc. Probably works because Caddy hides the problem, but should be verified in real setup if no gateway is in place.

Future considerations:

1. A more pessimistic locking flow with a room holding mechanism and a reservation timeout, system exclusively locks/holds the room for a specific duration so no one else can claim it, I would be less frustrated as a guest to know fail early in the process than try to book and fail eventually (makes more sense when there is payment in place).
2. Guests should have ability to view/cancel their reservations.
3. UI enhancments: date picker reflects the non-available dates, booking dialog persistence on error to retry fast.
4. More logging coverage.
5. More tests coverage. UI tests.
6. Server side pagination and filtering.
7. UI should be more nuanced to reflect guest/staff distinction.
8. I would think more about reverting the initial decision to use FluentValidation for a custom one. Had to manually call the validator and tunnel up the exceptions to the exception handling middleware to respect the custom response error schema.

[wiz-mewssystems]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	2
Software Management Findings	-
Total	2

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

Pull Request Developer Guidance

Action Required: Please review and fix any Critical or High severity findings identified above.

⚠️Current Mode: Warning only — PRs are not blocked
🚫 Coming Soon: PRs with Critical or High findings will be blocked (planned for Q2 2026)

Need help or have questions? Reach out to the Security team on Slack: #rnd-wiz