Why does joining a Python set of stop ids give a route-optimisation job a different cache key each run?

### What actually varies CPython randomises the hash of `str`, `bytes` and `datetime` objects. The interpreter picks a hash seed during startup, and every hash of those types folds that seed in, so the same string hashes to a different value in two different processes. Sets and dictionaries place their entries by hash, so the *iteration order* of a set of strings is a function of that per-process seed (plus insertion history and resize points). Nothing about your code changed; the bucket layout did. This defence exists for a reason. Without it an attacker who can choose keys — form fields, JSON keys, header names — can craft thousands of strings that collide, turning an average O(1) dictionary into a quadratic one and taking a service down with a single request. Randomising the seed makes that set of collisions unguessable. It has been on by default since 3.3 and remains so on 3.14. ### Why the cache key drifts A route-optimisation job that builds its key like `"|".join(stop_ids)` from a `set` is asking the hash table for an order the language never promised. Each worker process starts with its own hash seed, so the *same* logical set of stops produces a different key string in each one. The result is not a crash but a slow bleed: an 83% cache-hit rate that only holds while a single process serves the traffic, and collapses as soon as the job is spread over several workers or restarted between deployments. The entries are all still there — they are simply filed under key strings nobody will ever compute again. ### The fix is in the key, not the environment Make the serialisation order-independent: ```python stops = {"lisbon", "porto", "faro", "braga"} key = "|".join(sorted(stops)) ``` `sorted()` gives a total order that does not depend on hashing at all. The same move applies to mappings — `json.dumps(payload, sort_keys=True)` — and to any digest computed over a collection. While you are there, pin the text encoding explicitly: a key hashed from `key.encode("utf-8")` in one place and from a differently-encoded byte string in another produces two distinct cache entries for the same logical value, which is the same bug in a different disguise. `str` and `bytes` never compare equal to each other either, so a cache written with one and read with the other misses every time. ### Where PYTHONHASHSEED belongs `PYTHONHASHSEED` is read at interpreter startup. Setting it to `0` disables randomisation altogether; setting it to an integer fixes the seed to that value. Two constraints follow. First, it must be set in the environment *before* the process starts — assigning to `os.environ` inside the running program has no effect on the seed already chosen, and only affects children you spawn afterwards. Second, it is a diagnostic and reproducibility tool, not a production fix: pinning the seed in production restores exactly the collision predictability the randomisation was introduced to prevent, and it leaves the underlying bug — code that depends on set order — in place. Use it to reproduce a failing CI run locally, and fix the ordering dependence in the code. `sys.flags` records whether randomisation was enabled for the current interpreter, which is worth checking before concluding that "it is deterministic here". ### Catching this class of bug earlier Order dependence hides well because a single-process test run is internally consistent. Two habits expose it. Run the suite under at least two explicit, different hash seeds in CI, so any test that silently relies on set order fails on one of them. And for anything that must be stable across processes — a cache key, a checksum, a file name, a snapshot fixture — build it in a subprocess or a second run and assert the two agree, rather than asserting only that the function returns *something*. ### The neighbouring myth Dictionaries preserve insertion order — an implementation detail in 3.6 that became a language guarantee in 3.7. Sets got no such guarantee and never will: their order is an artefact of hashing and resizing. A candidate who has generalised "dicts are ordered now" into "sets are ordered too" is carrying exactly the assumption that produces this defect.