Extending a Session After the Screen Has Locked

01 / 05

The first failure came from reusing the wrong guard

A venue allowed a reservation to begin when the customer actually arrived. An early start preserved the original duration but shifted the start and end to real seconds. The extension path then incorrectly reused the half-hour boundary rule intended for creating a new booking.

The regression reproduced a 10:00 booking started at 09:37:24. Its original end was 10:07:24, and a 30-minute extension needed to produce 10:37:24. I removed the new-booking start guard from that cash extension path while retaining running-state, conflict, closing-time and maximum-duration checks. The repair did not redefine the venue’s ordinary reservation grid.

02 / 05

A completed session needs an explicit recovery transition

A later incident happened after the automatic end-of-session lock. Staff extended a customer, but the device stayed locked. Manually unlocking it did not stop the old delayed cleanup from exiting the practice session. The system had implemented ending and cleanup without the complete path back into an active session.

The recovery window was anchored to the confirmed device lock time. A successful extension restored the same booking and practice session, issued the unlock, scheduled the new end and invalidated the old cleanup. The window was venue-specific, and manual locking or compensation did not restart it.

03 / 05

The second report exposed the actual staff path

The next field report showed a direct device unlock, not a booking extension. The first service-level repair had therefore not been invoked. Although the interface described direct control as separate, it still offered an easy route that looked like the action staff needed.

I replaced that ordinary unlock entry point with Resume plus time during the recovery window. It reused the booking extension operation. The server also rejected a direct unlock in that window, so an old tab could not bypass the corrected flow. The schedule and booking views refreshed at session expiry to expose the recovery state.

04 / 05

A stale cleanup must not touch the next customer

Cleanup and extension shared the device lease boundary. A late task needed to recognize that its authority had been superseded, instead of clearing the newly restored session or affecting the next booking. The new end time still had to satisfy conflicts, opening hours, duration and financial-state checks.

The regressions covered automatic expiry, lock confirmation, recovery, the correct device-to-booking mapping, re-enabling and stale-cleanup invalidation. Production publication and read-only health checks were recorded for the repair. The record still requested a full field replay through the new Resume action, so backend health is not presented as proof of that physical replay.

05 / 05

Repair the business action all the way to the button

The incident changed how I reviewed an operational fix. The service could be correct while the person continued to choose a different control. A complete repair aligned the visible action, server guard, domain transition and delayed work. That is a stronger unit of delivery than a successful unlock response.