The Silent Bug: Dictionary Iteration Order

You write a function that iterates over a dictionary, generates a cache key from the results, and uses it to deduplicate work. It works perfectly in dev. Tests pass. You deploy to production and two weeks later, a customer reports inconsistent behavior.

What happened

In CPython 3.7+, dictionaries maintain insertion order. But "insertion order" depends on how the dictionary was built — and if you deserialize from JSON, load from a database, or merge from multiple sources, the order can differ between runs, machines, or Python versions.

The code works most of the time. Then one day the data arrives in a different order, the cache key changes, and your system does redundant work, produces different output, or breaks entirely.

The deeper issue

AI assistants treat dictionaries as naturally ordered data structures. They generate code like:

config_hash = hash(str(config_dict))

This produces a different hash depending on insertion order. Or they write API responses that serialize a dict and assume the client will see the same field order. These are time bombs that detonate under load or at scale.

What DET001 catches

DET001 flags any iteration over a dictionary that doesn't explicitly sort the keys first. It also catches patterns like hashing or serializing dictionaries without sorting, joining dict values into strings, and using dict ordering for comparison or deduplication.

The fix is almost always adding sorted(): for key in sorted(config.keys()). One word that prevents hours of debugging.