fix: Don't use a hash function for cache keys

[joshlarson]

Scope

Asana Ticket: 76 showing Quincy Center trip

The bug manifests non-deterministically, and in both directions - the 76 to Lincoln Labl sometimes shows a Quincy Center trip, and the 210 to Quincy Center sometimes shows the Lincoln Lab trip.

Implementation

The bug is due to a hash collision in the keys that the cache is using to store trips.

iex(1)> ["73869983", &MBTA.Api.Trips.by_id/2] |> :erlang.phash2(2 ** 32)
2202163778
iex(2)> ["74122563", &MBTA.Api.Trips.by_id/2] |> :erlang.phash2(2 ** 32)
2202163778

We fixed a similar issue in April, but only when args is a single-element array. Trip-lookup happens by way of a helper API call function (which is usually given a default value of MBTA.Api.Trips.by_id/2), so the special-case implemented in #2487 didn't work for trips.

Screenshots

How to test

To see the bug locally, visit Schedule Finder for the 201, and then visit Schedule Finder for the 76. The first visit will seed the collided cache for that trip with the 210 trip to Quincy Center, so when you scroll down on the 76 page to around 3:30PM, you'll see Quincy Center amid a sea of Lincoln Lab via Hanscom Airport's.

You can do the same in the opposite direction by visiting the 76 first and then the 201, but you may have to clear your cache first (Dotcom.Cache.Multilevel.flush() into an iex -S mix shell).

[thecristen]

🤯