A chat archiver's functools.cmp_to_key comparator returns 0 whenever it hits an error — what breaks?

## The scenario A chat-transcript archiver merges message batches from several sources and sorts them before writing a day's transcript. The ordering was ported from an older tool as a two-argument comparator and adapted with `functools.cmp_to_key`. Somewhere along the way a defensive `except` was added: ```python def cmp_message(a, b): try: return (a["ts"] > b["ts"]) - (a["ts"] < b["ts"]) except TypeError: return 0 # "don't let one bad record break the job" ``` Three weeks after the release train that shipped it, support reports that some archived transcripts read out of order — replies before the messages they answer. Nothing failed. No exception was logged. The job's exit status was zero every night. ## What actually broke `0` does not mean "I could not compare these". To a sort, `0` means **these two are equal in order** — a positive, load-bearing claim. The moment one record has a `None` or a string timestamp where the others have numbers, every comparison involving it returns `0`, and the comparator starts asserting that a broken message ties with *everything*. That destroys the property a sort requires: a **consistent total order**, where the relation is transitive and any two elements are related by exactly one of "before", "tied" or "after". Here `bad == x` and `bad == y` while `x < y`, which is a contradiction. Python's sort is a merge sort that builds runs and merges them; each merge trusts the comparisons it makes and does not re-check earlier ones. Fed contradictory answers it still terminates and still returns a list of the right length with all the original elements — just not in a correct order, and the misplacement is not confined to the malformed record. Good messages end up on the wrong side of the tie and travel with it. Two properties make this a nightmare to diagnose. First, **CPython does not detect it**: there is no validation of the comparator and no error when merges disagree, so the failure has no signal at all. Second, the sort is **stable**, so wrongly-tied elements retain their relative *input* order. The output therefore depends on the order in which batches happened to be concatenated — which changes with source availability and retry timing. The bug reproduces on Tuesday's archive and not on Wednesday's, looks like a race, and survives review because the `except` clause reads like defensive programming. ## Confirming it Start by proving the fallback branch is being taken at all, since by construction it leaves no trace. Replace the bare `return 0` with a counter and a log line — `logging.exception` in that `except` gives you the type and the offending record. If the count is non-zero on real input, you have your answer without any further theory. Then confirm the ordering claim independently. Re-sort a captured batch with a strict comparator that re-raises instead of swallowing; if it now raises `TypeError` on a record whose timestamp is `None` or a `str`, the malformed data is confirmed. A second check is to re-run the same batch with its input order shuffled: a correct total order gives the same output every time apart from genuine ties, so output that changes with input order is proof that elements are being wrongly tied. ## Fixing it The immediate fix is to stop lying. A comparator that cannot compare two elements should let the exception propagate: the sort aborts, you see the record, and — importantly — a partially sorted `list.sort` leaves the list in a modified but valid state, so operate on a copy or use `sorted()` if you intend to recover. The better fix is structural, and it also removes the adapter's cost. This ordering is a plain single-field ordering, so it belongs in a key function, not a comparator: ```python import operator rows.sort(key=operator.itemgetter("ts")) ``` A key function is evaluated once per element, so a malformed timestamp raises immediately, attached to *its own* record rather than to a pair, and the traceback names the value. It also removes one Python-level call per comparison, which on a day's transcript volume is the difference between a noticeable pause and none. Where the ordering is genuinely multi-field — timestamp then source then sequence — a tuple key expresses it directly. The durable fix is at the boundary: parse and normalize timestamps at ingest, so that everything downstream holds one type. Comparison-time coercion is the wrong layer; it turns a data-quality problem into an ordering problem and puts the guess in the hottest code path in the job. ## The rule to carry away `except: return 0` inside a comparator is not resilience, it is fabricated data. Any error handler that must produce an answer where none exists should either raise, or route the element to an explicit, documented position — for example sorting unparseable records last by a key that says so — so the choice is visible in the output instead of hidden in an exception handler.