Add room booking system for members

[wearsshoes]

Summary

• Add room booking feature allowing logged-in members to reserve meeting rooms and call booths marked as "bookable" in Airtable
• Created new "Room Bookings" table in Airtable with fields: Room (link), Booked By (link), Start, End, Purpose, Status
• Multi-room calendar view showing all bookable rooms side-by-side with hourly slots (8am-10pm)
• Conflict detection prevents double-booking
• Users can view and cancel their own bookings

Changes

• app/lib/airtable.ts - Added Rooms and RoomBookings to Tables constant
• app/lib/room-bookings.ts - New library with booking helper functions
• app/portal/api/rooms/route.ts - GET endpoint for bookable rooms
• app/portal/api/room-bookings/route.ts - GET/POST for listing and creating bookings
• app/portal/api/room-bookings/[id]/route.ts - DELETE for cancelling bookings
• app/portal/book-room/ - New booking UI with form and day calendar view
• app/portal/page.tsx - Added link to book-room section

Test plan

• Navigate to /portal/book-room when logged in
• Select a room and time slot, create a booking
• Verify booking appears in calendar grid (marked with x)
• Verify booking appears in "your bookings" list
• Try to double-book same slot - should show conflict error
• Cancel a booking - should remove from list

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
mox-sf	Ready	Preview, Comment	Jan 29, 2026 7:53am

[claude]

Code Review

Found 1 issue during review:

Race Condition: Time-Of-Check to Time-Of-Use (TOCTOU) in Booking Creation

Location: app/portal/api/room-bookings/route.ts lines 90-135

Issue: This endpoint has a race condition that could allow double-bookings for the same room and time slot.

The code checks for conflicts with findConflicts() (lines 90-103), then creates the booking in a separate operation (lines 127-135). Between these two operations, another concurrent request could pass the same conflict check, and both requests would proceed to create overlapping bookings.

Why This Is Significant:
The gap between check and create includes multiple network round-trips:

• Airtable query for conflict detection
• Airtable query for getRoom() (lines 106-113)
• Potential query to fetch user details (lines 119-124)
• Airtable create operation

This creates a realistic window for race conditions, especially when multiple users are booking popular rooms simultaneously (e.g., at the start of a workday).

Code Reference:

mox-sf/app/portal/api/room-bookings/route.ts

Lines 89 to 136 in e87d8a5

	// Check for conflicts
	const conflicts = await findConflicts(roomId, start, end)
	if (conflicts.length > 0) {
	return NextResponse.json(
	{
	error: 'Time slot is already booked',
	conflicts: conflicts.map((c) => ({
	startDate: c.startDate,
	endDate: c.endDate,
	})),
	},
	{ status: 409 }
	)
	}
	// Get room details
	const room = await getRoom(roomId)
	if (!room) {
	return NextResponse.json({ error: 'Room not found' }, { status: 404 })
	}
	if (!room.bookable) {
	return NextResponse.json({ error: 'Room is not bookable' }, { status: 400 })
	}
	// Get user details
	const userId = session.viewingAsUserId || session.userId
	const userName = session.viewingAsName || session.name || ''
	// If we don't have the name from session, fetch it
	let finalUserName = userName
	if (!finalUserName) {
	const userRecord = await getRecord<PersonFields>(Tables.People, userId)
	finalUserName = userRecord?.fields.Name || 'Unknown'
	}
	// Create the booking
	const booking = await createBooking({
	roomId,
	roomName: room.name,
	userId,
	userName: finalUserName,
	startDate: start,
	endDate: end,
	purpose,
	})

Suggested Fixes:

1. Optimistic concurrency control: After creating the booking, re-check for conflicts and delete the booking if conflicts appeared
2. Unique constraint: Use Airtable automations/scripting to enforce atomicity
3. Distributed locking: Implement locking around the check-and-create sequence
4. Accept the risk: Document that double-bookings are possible and provide admin tools to resolve them

The first option (optimistic concurrency) is likely the most practical for Airtable-based systems.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.