do not conflict.

Request States

Requests can have one of these states:

CONFIRMED
WAITLISTED
CANCELLED
COMPLETED

• A WAITLISTED request has no room or booking assigned.
• A CANCELLED request is terminal and must never be promoted.
• An active request is one whose state is CONFIRMED or WAITLISTED.
• CANCELLED requests are not active.

A submission sequence is assigned when requestRoom is called and never changes.

Booking IDs should be generated deterministically, for example:

B1, B2, ...

in confirmation order.

Required Operations

Students are fixed from:

u1 to u10

Facilities are:

AC
ACCESSIBLE
ATTACHED_BATHROOM

getRoomBookings, getStudentBookings, and getWaitlistedRequests must return deterministic ordering as specified below.

1. Add a Room

addRoom(roomId, capacity, facilities)

Return the room ID.

Rules:

• Capacity must be positive.
• Facilities must be valid.
• Facilities must not contain duplicates.
• Reject an existing room ID without changing the existing room.

2. Submit a Booking Request

requestRoom(
    requestId,
    studentId,
    guestCount,
    requiredFacilities,
    startDay,
    endDay
)

Return:

• request status
• bookingId
• roomId when confirmed

Validation:

• Student must be valid.
• Guest count must be positive.
• Facilities must be valid.
• Facilities must not be duplicated.
• Request ID must be unique.
• endDay > startDay.

Reject the request if the student already has an overlapping active request, including an overlapping waitlisted request.

Then run the room allocation rules.

• If a suitable room exists, confirm the request.
• Otherwise, store it as WAITLISTED with no room assignment.

3. Check Room Availability

isRoomAvailable(roomId, startDay, endDay)

Return:

true / false

Return false when any active booking overlaps the requested half-open interval.

Adjacent stays do not overlap.

Example:

[2,5) and [5,8)

are compatible.

Invalid ranges and unknown rooms should return an error rather than false.

4. Find the Best Room

findBestRoom(guestCount, requiredFacilities, startDay, endDay)

Return:

• selected room ID, or
• null when no eligible room exists.

Apply:

• capacity
• facilities
• availability
• exact tie-breaking order from the Allocation Rules.

This method must not create a request or mutate booking state.

5. Cancel a Request

cancelRequest(requestId)

Return:

• the cancelled request status
• plus a possibly empty list of promoted requests.

Rules:

• A waitlisted request is removed from active waitlist consideration.
• A confirmed request releases its room interval and then triggers waitlist processing.
• Attempting to cancel an already cancelled request returns an error and changes nothing.

6. Process the Waitlist

processWaitlist()

Return the list of promoted requests with their:

• booking ID
• room ID

Consider active waiting requests by:

1. Submission sequence
2. Request ID

For each request, re-run the same best-room allocation rules.

Leave incompatible requests waiting and continue to later requests.

Important: An older request requiring a four-person accessible room must not block a later request that can use an available two-person AC room.

7. Get Request Status

getRequestStatus(requestId)

Return request details including:

• status
• stay interval
• guest count
• facilities
• assigned booking ID and room ID when confirmed

Unknown request IDs return an error.

8. Get Room Bookings

getRoomBookings(roomId)

Return the room's active bookings, sorted by:

1. startDay
2. Request ID as a tie-breaker

Cancelled bookings are not active and must not block availability.

9. Get Student Bookings

getStudentBookings(studentId)

Return all requests belonging to the student, including:

• confirmed
• waitlisted
• cancelled

Order them by submission sequence.

Unknown students return an error.

10. Get the Active Waitlist

getWaitlistedRequests()

Return active waitlisted requests ordered by:

1. Submission sequence
2. Request ID

Cancelled or confirmed requests must not appear.

Interactive Command-Line Experience

Provide a numbered menu exposing all ten operations above, plus:

Exit

An equivalent REPL or command-based interface is acceptable if nothing is missing.

Print a clear result after every operation and return to the menu.

Example Scenario

Use this scenario to validate:

• interval handling
• best-fit selection
• waitlist promotion

Setup

Create:

R1: capacity 2, facilities [AC]

R2: capacity 2, facilities [AC, ATTACHED_BATHROOM]

R3: capacity 4, facilities [ACCESSIBLE, ATTACHED_BATHROOM]

R4: capacity 4, facilities [AC, ACCESSIBLE, ATTACHED_BATHROOM]

Best-Fit Check

Submit a request for:

u1
2 guests
AC
[10,13)

R1, R2, and R4 satisfy the request.

The result must use:

R1

because it has the smallest sufficient capacity and fewer extra facilities than R2.

Adjacent-Stay Check

Submit another two-person AC request for:

[13,15)

It may use R1 because:

[10,13)

and

[13,15)

do not overlap.

Waitlist Check

When all compatible rooms are occupied during:

[11,12)

another two-person AC request should return:

WAITLISTED

with no room or booking ID.

Cancellation and Promotion Check

Cancel a confirmed booking that frees a compatible room.

The waiting request should then be reconsidered and confirmed in the best available room.

Required Edge Cases

The implementation must handle:

• Duplicate room ID
• Duplicate request ID
• Unknown student
• Unknown room
• Unknown request
• Unknown facility
• Zero capacity
• Negative capacity
• Zero guest count
• Negative guest count
• endDay <= startDay
• Duplicate facilities
• Partial and exact interval overlaps
• Adjacent intervals that do not conflict
• Room has sufficient capacity but is missing a required facility
• Student with an overlapping active request
• Overlapping waitlisted request for the same student
• Cancellation of both confirmed and waitlisted requests
• Attempting to cancel an already cancelled request
• Cancelled requests must never be promoted
• Cancelled bookings must not block availability
• Older incompatible waitlist requests must not block compatible later requests
• Deterministic ordering for all returned collections
• Deterministic booking IDs in confirmation order