How do you walk a Python exception's __cause__ and __context__ to the root failure when only the wrapper is reported?

### The rule you are reimplementing A chained exception is a linked list with two possible next-pointers, and the default traceback picks between them with a fixed precedence: `__cause__` if it is not `None`; otherwise `__context__` if `__suppress_context__` is `False`; otherwise nothing. Any code that wants the root cause — an error reporter, a log enricher, a test asserting on a wrap — follows the same rule. ```python def chain(exc): seen = set() while exc is not None and id(exc) not in seen: seen.add(id(exc)) yield exc if exc.__cause__ is not None: exc = exc.__cause__ elif not exc.__suppress_context__: exc = exc.__context__ else: exc = None try: try: raise ImportError("partially initialized module") except ImportError as err: raise RuntimeError("loader registry failed") from err except RuntimeError as top: print([type(e).__name__ for e in chain(top)]) ``` The `seen` set is not decoration. CPython refuses to build a `__context__` loop when it sets the attribute implicitly, but `__cause__` is assignable, and two exceptions can be made to point at each other in a few lines of ordinary code. A reporter that hangs while formatting an error is a bad failure to debug. A deliberate variant is to ignore `__suppress_context__` when walking. The display rule exists to keep tracebacks readable for humans; a machine reporter can reasonably follow `__context__` even when it was suppressed, because the link is still on the object and the root cause is what it is after. Decide that once, document it, and keep it consistent — otherwise two dashboards disagree about the same incident. ### The scenario this actually shows up in A clinical-lab result loader imports analyser plugins from a registry at startup. One release introduces a circular import between the registry and a plugin, so importing it raises `ImportError`. The registry catches `ImportError`, raises its own configuration error, and the startup path logs a formatted message. What the on-call engineer sees is one line naming the plugin as unavailable, with no file, no cycle and no import chain. With a 4-person team and no one who has seen this failure before, that line burns an afternoon. Two things are wrong, and only one of them is the walk. The visible symptom is that the reporter lost the chain; the deeper cause is that the error path threw the exception object away and kept a string. Fixing the reporter to accept the exception, walk the chain and emit the root type and message as separate fields makes the same incident a two-minute read — and makes it searchable, because "root_type: ImportError" is a field you can aggregate over, while a formatted message is not. ### What to emit A chain walk is most useful when it produces structure rather than more prose: * the reported exception's type and message — what the layer called it; * the root exception's type and message — what actually happened; * the depth of the chain, and whether each hop was a cause or a context. The cause/context distinction is diagnostic in itself. A hop through `__cause__` was a deliberate translation by a developer; a hop through `__context__` was the interpreter noticing a second failure inside a handler. A chain that is all causes is a well-layered system reporting itself; a chain with unexpected context hops usually means a handler broke while handling. ### Retention, and where the walk should live Exceptions keep their `__traceback__`, tracebacks keep frames, frames keep locals — and a chain multiplies that by its length. Walking a chain is cheap, but *storing* the exceptions you walked is not: a cache of "recent errors" holding exception objects can pin a large amount of memory, including whatever those frames had loaded. Extract the fields you need, then drop the reference. The same reasoning explains why CPython deletes the `as` name at the end of an `except` block. Put the walk in one place — the error reporter or logging integration — not at every call site. Scattered ad-hoc `while exc.__cause__` loops drift apart, disagree about `__suppress_context__`, and are exactly the sort of code that acquires an infinite loop under a hand-assigned cause. ### Version notes The attributes and the precedence rule are stable across the whole Python 3 line and unchanged in 3.14, so a walker written against them needs no version guards.