I explicitly tested this scenario last week. The system has a single eligibility time that it sets when you book a LL reservation. The expiration of a reservation is only indirectly tied to eligibility time, sometimes.
Every time you book a G+ LL reservation, it sets a eligibility return time, which is the earlier of the end of the reservation return window and 2 hours from the current time (or 2 hours from the park opening time if you’re booking before opening time). Every time you book, it sets a new time and there’s only one time it’s tracking.
So if it’s 9:00 am and you book a 10:15-11:15 am reservation, the eligibility time is set to 11:00 am. If you wait until 11:00, the eligibility time hits and you can book, but that new booking sets a new eligibility time. Say you booked a 11:30-12:30 at that point. Now your eligibility time is 12:30. If you wait until 11:15, nothing happens. You can still tap in and regain eligibility, but the expiration of your 10:15-11:15 reservation does nothing, because that was never set as an eligibility time in the first place.
The confusion arises because tapping in on any reservation resets eligibility, and canceling any reservation resets eligibility, so it’s easy to think that expiration of any reservation would reset eligibility. But it doesn’t work that way.
So in programming terms (speaking to the general audience here, not specifically
@dmunsil, who I suspect already understands this):
Tapping into or cancelling a ride are actionable "events" that the system can respond to. That is, when one of those things happen, the system is explicitly "aware" it has happened and can/will take actions to handle it. The expiration time of a ride, on the other hand, is a passive event that the system isn't actively aware of; it just happens in the background, without anyone actually
doing anything, and the system doesn't necessarily immediately "know" that something has changed.
Based on what we know about how the system is working, I strongly suspect the implementation is something like this:
- When a LL is booked, a timestamp is set tracking the next eligible booking time**
- When an existing LL is used ("tapped in") or cancelled, the eligibility timestamp is cleared
- The user can book a new LL if (and only if) no timestamp is set, or it is in the past. In practice, the way this likely works is that whenever a page is loaded that might allow a LL pass to be booked, the system does a check on any existing timestamp against the current time, and clears the timestamp if it is in the past.
** Until
@dmunsil posted the information above, I assumed that the next eligible booking time would be set based on the 120 minute rule (adjusted for park opening) or the expiration time of the earliest LL pass currently booked, whichever was earlier. But based on this new clarification, it sounds like they've taken the even simpler option of setting the timestamp based on the earlier of the 120 minute timeout window and the expiration time of the LL just booked. This has important implications for someone who understands specifically how the system works and is trying to maximize it, but will go completely unnoticed by the vast majority of users, who will not typically be purposely letting a LL expire with the expectation of then being able to immediately book another.
My personal opinion is that the major result of these implementation choices - ie. the ability to hold and rebook multiple LL passes throughout the day - was deliberate, or at the very least well understood by the system developers. Anyone with programming or UI design experience will recognize that more nuanced handling of "extra" passes created when the 120 minute eligibility timer expires would quickly become complicated, both technically, but especially in terms of the user's ability to understand the system. I think they deliberately erred on the side of simplicity, with the understanding that the "no re-ride" rule and the capacity of the system would naturally limit its use.
The "loophole" created by the 15-minute grace period was probably an oversight, or maybe a known consequence that they decided to allow. The only sensible way to "fix" it would be to set the expiration timer at the end of the 15-minute grace period, instead of the official end time of the LL window. That
should be a really easy change. But it might create a source of confusion for users who are not aware of the grace period, and maybe they don't want to draw attention to it? As long as the loophole doesn't have any significant impact on the overall system (and it seems unlikely it would, considering how few people will understand it, let alone make the effort to exploit it), they
might just decide to leave it alone.
My thanks (again!) to
@dmunsil for the clear and unambiguous test results!