How do you get a transcript id onto every logging.LogRecord without passing it through every function?

The requirement — every log line carries the identifier of the work in progress — is the canonical use of a `contextvars.ContextVar`, and the interview value is in wiring it to `logging` correctly rather than in the variable itself. **The scenario.** A chat-transcript archiver processes transcripts one at a time on a small pool of long-lived workers, for a 4-person team whose conversations interleave. When a transcript gets archived twice, the operators' first question is "which transcript, and which run" — and log lines that carry no identifier cannot answer it. Threading a `transcript_id` parameter down through the parser, the redactor and the writer is the alternative, and it is exactly what nobody wants: every helper's signature grows a parameter it does not use, and any code path that forgets it logs anonymously. **Piece one: the variable.** Declare it once at module level, with a default: ```python transcript_id = contextvars.ContextVar("transcript_id", default="-") ``` The default is load-bearing, not decoration. The filter you are about to write runs for *every* record the handler sees — start-up lines, third-party library chatter, shutdown messages — most of which happen outside any archive job. A bare `get()` there would raise `LookupError` inside the logging machinery. **Piece two: the filter.** `logging.Filter` is not only for dropping records; its `filter()` hook is the supported place to *decorate* one. Subclass it, set the attribute, return `True`: ```python class TranscriptFilter(logging.Filter): def filter(self, record): record.transcript_id = transcript_id.get() return True ``` Choose an attribute name that does not collide with `LogRecord`'s own — `name`, `msg`, `args`, `levelname`, `module` and friends are already taken, and overwriting one corrupts formatting for every handler. Then the formatter can name it: `logging.Formatter("[%(transcript_id)s] %(message)s")`. **Piece three: where the filter is attached.** This is the detail that separates candidates. Filters attached to a `Logger` run only for records logged *through that logger* — `Logger.handle` applies the logger's filters before dispatch, and records propagated up from child or library loggers are already past that check. Filters attached to a `Handler` run for every record the handler is about to emit, whatever logger created it. Since the goal is "every record in the output carries the id", attach the filter to the handler. In a `logging.config.dictConfig` this is the difference between listing the filter under a logger and listing it under the handler. **Piece four: the scope.** At the entry point of each job: ```python token = transcript_id.set(chat_id) try: archive(chat_id) finally: transcript_id.reset(token) ``` The `finally` is the operationally important half. Workers are reused: if an exception skips the reset, the *next* transcript is logged under the previous id. The symptom is grim precisely because it is plausible — the logs show one transcript apparently written twice and another never touched, so the duplicated side effect is chased in the archiver's write path when the real defect is in the logging scope. On Python 3.14 the same pairing is `with transcript_id.set(chat_id):`, since the token is now a context manager. **What goes wrong without the default.** If a record reaches the handler with no `transcript_id` attribute, the formatter's percent-interpolation fails. `logging` catches that inside `Handler.emit`, calls `handleError`, and prints a traceback to stderr — the record itself is dropped. So one unstamped code path costs you the very log line you were trying to enrich. Either the filter is on the handler and always sets the attribute, or the formatter must tolerate its absence. **Alternatives worth naming.** `logging`'s `extra=` keyword does the same decoration per call: `log.info("...", extra={"transcript_id": chat_id})`. It works, but it puts the burden back on every call site — the problem you set out to solve — and it refuses keys that clash with reserved `LogRecord` attributes. `logging.setLogRecordFactory` can wrap the factory so every record is born with the attribute, which is a reasonable process-wide alternative to a handler filter; the filter is usually preferred because it is scoped to the handler you control rather than to the whole process. Creating a child logger per transcript is the wrong answer: loggers are cached forever in the logging manager, so a per-transcript logger name is an unbounded, uncollectable registry. **Structured output.** Once the attribute exists on the record, a JSON formatter can emit it as a field rather than baking it into the message text, which is what makes the id filterable in a log store. That is the real payoff over appending the id to every message string by hand.