Why is the traceback missing when a child process's exception is re-raised in the parent?

**What a traceback actually is.** `exc.__traceback__` is not text. It is a chain of traceback objects, each pointing at a frame object, which in turn points at a code object, the local and global namespaces of that frame, and the instruction offset. Those references reach into the running interpreter: compiled bytecode, live objects, possibly open files and sockets sitting in locals. None of that is serializable, and serializing it would be meaningless anyway -- the frames belong to an interpreter that is about to exit. `pickle.dumps(exc.__traceback__)` says so plainly: `TypeError: cannot pickle 'traceback' object`. **So what does cross?** Only what `BaseException.__reduce__` yields: the class reference, `args`, and the instance dictionary as state. Three things people expect to survive do not: * `__traceback__` -- gone, for the reason above. * `__cause__` -- the exception attached by `raise ... from`. It is a C-level slot, not an entry in the instance dictionary, so it is not part of the pickled state. * `__context__` -- the implicit chaining set when one exception is raised while another is being handled. Same reason. All three come back as `None`. That is the real sting: not only is the child's stack missing, the *chain* is missing too, so a carefully wrapped `raise DomainError(...) from driver_error` arrives in the parent as a bare `DomainError` with no trace of what caused it. The stack the parent then prints starts wherever it re-raised the copy -- the line that asked for the result -- which is exactly the least informative place in the program. **Notes are the exception to the rule.** A note attached with `BaseException.add_note` is stored on the instance, so it lands in the instance dictionary and *does* pickle. That makes notes the cheapest reliable channel for diagnostic text across a process boundary. Format the traceback where the frames still exist and attach the string: ```python try: scrape(target) except Exception as exc: exc.add_note(traceback.format_exc()) raise ``` When the parent prints the reconstructed exception, the note prints with it, and you see the child's stack as text. **Do not try to ship a smarter object.** The obvious idea -- serialize `traceback.TracebackException`, which is designed as a lightweight capture -- does not work on 3.14: its frame summaries hold code objects, and pickling one raises `TypeError: cannot pickle code objects`. Format it to strings first, then send the strings. The rule generalises: cross-process diagnostics are text or plain data, never live objects. **Why some parent-side tracebacks look doubled.** Machinery that returns results already applies this idea. It formats the child's traceback into a string, wraps that string in a placeholder exception, and chains it onto the copy it re-raises in the parent. The output then shows the child's stack as text, a chaining line, and then the parent's real stack. Recognising that shape is a practical skill: the upper block is a rendering of something that happened in another process and its frames no longer exist, so a debugger cannot step into them. **Designing for it.** Treat the child as the only place where good diagnostics can be produced. Log the full failure there, with the target identity in the message, before anything crosses. Attach the formatted trace as a note or as a plain-data field on a purpose-built exception. Include the worker's identity, since the parent otherwise cannot tell which of many workers failed. Concretely: a metrics scraper fanning out across a 17-service dependency graph should have every worker log its own failure with the service name attached; a parent that only re-raises copies will tell you that something failed 17 times and nothing about where. **And remember the case with no exception at all.** If the child dies during startup -- an import cycle in a fresh interpreter under `spawn` or `forkserver` -- there is no exception object to format, no note to attach and no copy to re-raise. The child's stderr and its exit status are the only evidence, which is one more reason to capture worker stderr rather than discard it. **One more thing worth carrying.** Since the copy has no stack, it also has nothing that identifies which unit of work produced it. Put that identity in the exception's own data -- the target, the batch, a correlation id -- rather than trusting a log line the parent will have to join up by timestamp. It costs one field and it is the difference between a report you can act on and one that says only that something, somewhere, failed.