Hacker News Reader

Comment by Terr_ | Hacker News Reader

Perhaps some sort of UUID collision in terms of cookies/sessions?

Or perhaps a caching issue?

I'm going to go with caching issues + interactions with Sabre backend. Also, did you know that your confirmation code, aka record locator is not globally unique? They are 6-character sequences like KZVGX5, so as you might imagine with the number for passengers flying, it doesn't take long to exhaust the namespace.

Alaska uses 6 letters. 26^6 is a bit over 300 million codes. Each year there are about 5 billion air passenger boardings, so while the whole of aviation runs through that space every 3 weeks, any individual airline takes much longer.

Would it also include digits? If so, 36^6, which is 2.1B

Each record locator is unique not by airline but for gds, in this case Sabre. Each record locator reference a reservation which may include many flights and people that fligth together in a trip. And a reservation is done 1 year in advance. It’s not a easy math

The letter/digit-space is per GDS, not per-airline/industry, however different airlines can have particular additional restrictions on codes. Some airlines don't allow 0 and O (i.e. Qantas), others don't allow I and 1, and others always/usually have the same ending letter (unless code-sharing).

Another thing to note is (unless something's changed in the 15 years since I left the airline industry) that non-trivial booking changes (i.e. not just passenger information changes) generally result in a new PNR being generated to replace the old one, effectively using up the old code.

A PNR is not supposed to be unique. It literally is a record, that is tied to the airline ticket stock code (first three digits of a ticket number) and booking system (Sabre/amadeus) until recently a gds was not able to query one or the other (and yeah there are more, even ticketless/couponless ones)

Thats why you are required to have two to verify, ticket number or last name but in old old systems you always used the ticket number as that had all the passenger information, coupon status, route, etc the PNR is just a shortcut to facilitate this.

Originally the PNR when the reservation systems where built in the 1960’s and 70’s the six / seven / eight digit reference was the hash of the physical location in memory of the booking. It would take very few cpu cycles to recall the booking.

Nowadays of course the booking reference is virtual.

Should I read this as a reversible hash? I can't imagine it works this way, have you got any pointers to learn more about early sabre ?

You can read here https://www.jstor.org/stable/249202?read-now=1#page_scan_tab... I am sure there are other resources available.

Yeah, I bet anything this is a caching issue. I assume there's a part of the page which one layer of templates expects to be cacheable, and then someone added this dynamic promotional upgrade feature inside of it, so it keeps being stored into the cache with random people's details in it, whoever was there each time there was a cache miss.

If this is some content that isn't always shown, it could be semi-rare for the upgrade message to show up at all, which is how this kind of thing sneaks past basic QA. Also sometimes QA is operating with low traffic, such that you might still just see your own information simply because you're the only one using the site right now.

Reply on news.ycombinator.com