Stage 5 · L24

Model rental state transitions

Core · original Session 5

A rental's state describes its business lifecycle. This checkpoint permits active and checked_in. The database CHECK restricts the vocabulary; the service restricts the allowed transition. Creating a rental starts active. Check-in changes an active rental to checked_in without changing its identity or quantity.

Repeat check-in is deliberately safe: the service sees checked_in and returns that same state. It does not increment Equipment.quantity. Available capacity is derived from stock minus the sum of active rental quantities, so a repeated check-in cannot restore stock twice. This is a concrete idempotent transition under this contract, not a promise that every POST is idempotent.

The check-in service resolves the rental's immutable equipment reference, locks that equipment row, then locks and rereads the rental. Reservation uses the same equipment-first lock order. Consistent lock ordering reduces competing-operation deadlocks and ensures the capacity decision shares one coordination point.

A missing rental is 404 and no row changes. An attempted delete of equipment with rental history conflicts, retaining the record link. Administrative permission later controls who may request the transition; it does not bypass valid states or create extra capacity. Keep state, authorization and stock as distinct rules.

New rental → active; Check-in → checked_in; Repeated check-in → checked_in; Only active can transition

Follow the running code

Focused lesson example; see the end-of-stage capstone for the cumulative app · stage 05

def next_state(current):
    if current == 'active':
        return 'checked_in'
    if current == 'checked_in':
        return current  # Repeat does not invent another transition.
    raise ValueError('Unsupported state')

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided lab

Read the explanation and predict the focused example’s outcome.
Predict first check-in, repeated check-in and an unsupported state. Distinguish state from catalogue stock.
Compare the observed outcome with the focused answer and state its boundary.

Expected: active becomes checked_in once; a repeat returns the completed state; an unsupported value is rejected. Completion removes an active rental from future allocation calculations; it does not increment the item's total stock. The single-operation state rule is separate from concurrent capacity coordination, taught next.

A second call must not repeat the completed transition; invalid source/target states need an explicit rejection rule.

Focused exercise and answer

Complete this focused exercise before reading its answer. The full native transfer is introduced only at the end of the stage.

Your transfer task: Predict first check-in, repeated check-in and an unsupported state. Distinguish state from catalogue stock.

Predict first check-in, repeated check-in and an unsupported state. Distinguish state from catalogue stock.

Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

active becomes checked_in once; a repeat returns the completed state; an unsupported value is rejected. Completion removes an active rental from future allocation calculations; it does not increment the item's total stock. The single-operation state rule is separate from concurrent capacity coordination, taught next.

Check your reasoning

Why is repeating this check-in safe?

Show the explanation

The second call observes the completed state and makes no additional allocation change.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.