In a log-ingest worker, a `finally` block's flush raises while a parse error is already propagating — which error reaches the caller?

This is exception **masking**, and it is a different failure from the one people usually associate with `finally`. A `return`, `break` or `continue` in a `finally` block *discards* the in-flight exception outright — it is gone, unlogged, unrecoverable. A `raise` in a `finally` block does not discard it: the new exception propagates, and the original is attached to it as `__context__`. ### What the caller actually gets ```python def flush_batch(): try: raise ValueError("record 41 is malformed") finally: raise OSError("connection reset while flushing") ``` The caller receives the `OSError`. The `ValueError` survives on `exc.__context__`, and the default traceback prints both, separated by: ``` During handling of the above exception, another exception occurred: ``` This is Python's *implicit* chaining: whenever an exception is raised while another one is being handled — and a `finally` block runs with an exception in flight — the interpreter records the older one in `__context__`. That is distinct from `__cause__`, which is set only when you write `raise New() from old` and prints "The above exception was the direct cause of the following exception". Implicit chaining is why the diagnosis is usually recoverable from logs: the root cause is in the traceback, just not at the top. ### Why it still hurts in production The damage is not to the traceback, it is to **type dispatch**. Every `except` clause between the failure and the top of the stack now sees the cleanup error's type, not the original's. In a log-ingest worker that means the layer above stops behaving the way it was designed to: * the handler written as `except ValueError:` — "malformed record, drop it and move on" — never fires; * the handler written as `except OSError:` — "transport blip, retry the batch" — fires instead; * so a batch that was *already partly written* before the parse error is retried in full at a 1,200-request-per-minute peak, and the tail of it lands twice. The visible symptom is a duplicated side effect with no corresponding error in the metrics that count `ValueError`s, which sends the investigation to the wrong subsystem. Worse, the shape is load-dependent: cleanup that only fails when a connection pool is exhausted masks nothing at low volume and masks everything at peak, so the bug appears exactly when the traffic makes it expensive. Note also that PEP 765's 3.14 `SyntaxWarning` does **not** cover this case. It flags `return`, `break` and `continue` leaving a `finally` block; a `raise` — or an ordinary call that happens to raise — is not a syntax-level pattern and is never flagged. This one is found by reading code, by review, or by the incident. ### Making cleanup unable to mask The rule is that cleanup must not change which exception the caller sees. Three practical shapes: **Contain the cleanup failure.** Wrap the cleanup in its own `try`/`except` and log it. The original propagates untouched, and the cleanup error is still recorded: ```python try: process(record) finally: try: flush_connection() except OSError: logging.getLogger("ingest").exception("cleanup flush failed") ``` Calling `logging.Logger.exception` inside an `except` block writes the full cleanup traceback, so nothing is lost — the information moves from the exception channel to the logging channel, which is where a secondary failure belongs. **Surface both deliberately.** When both failures genuinely matter to the caller, raise an `ExceptionGroup` (available since 3.11) built from the two exceptions, and let the caller destructure it with `except*`. This is honest about there being two problems, at the cost of a caller that must be written to expect a group. **Make cleanup incapable of failing.** Best where it is achievable: cleanup that closes an already-closed handle, decrements a counter, or releases an in-process resource should be written so there is nothing left to raise. ### The operational half of the answer Fixing the masking restores the right error type, but it does not undo the duplicated writes. A retry path that can re-send a partly-applied batch needs an idempotency key or per-record deduplication regardless of which exception it sees — masking merely made the retry fire in a case the designers never intended. A senior answer names both halves: cleanup that cannot change the exception type, and a write path that survives being retried. It is also worth adding an assertion to the incident's postmortem tooling: an alert on `__context__` being non-`None` at the top-level handler is a cheap, direct signal that some cleanup path is masking real failures somewhere in the service.