Why does mutating decimal.getcontext().prec in one queue worker change later jobs' totals?

### What getcontext actually returns `decimal.getcontext()` does not return a snapshot or a copy. It returns *the* current `decimal.Context` object — a mutable object holding `prec`, `rounding`, the exponent limits, the trap settings and the accumulated signal flags — and every arithmetic operation on a Decimal reads it at the moment it runs. So `getcontext().prec = 6` is not a parameter you passed to a calculation; it is a change to shared state that the next calculation, in any function, will pick up. In a queue worker this is exactly the wrong shape. A job that widens precision for one delicate computation and never puts it back leaves every subsequent job on that thread computing at the wrong precision, and the symptom appears in totals produced by code that never mentions the decimal context at all. Because the change survives only in the thread that made it, the bug is order- and scheduling-dependent: it shows up when a particular job runs before another on the same worker, and vanishes the moment you reproduce it alone. A batch big enough to keep several workers busy — say a 2.4 GB working set of documents queued for conversion — reorders jobs across restarts, which is precisely the environment in which "the totals changed and nothing in that code changed" gets reported. ### Scoping the change properly `decimal.localcontext()` is the intended tool. It copies the current context on entry, gives you the copy to modify, and restores the previous context on exit — including when the block raises, which hand-rolled save-and-restore code routinely gets wrong: ```python from decimal import Decimal, getcontext, localcontext getcontext().prec = 28 with localcontext(prec=6) as ctx: print(ctx.prec, Decimal(1) / Decimal(7)) print(getcontext().prec, Decimal(1) / Decimal(7)) ``` That prints `6 0.142857` and then `28 0.1428571428571428571428571429`. Passing the attributes as keyword arguments requires Python 3.11 or later; before that you write `with localcontext() as ctx:` and set `ctx.prec = 6` on the first line of the block. Either form is safe. ### Threads, tasks and how far the change travels The current context is per thread: a newly started thread does not inherit the caller's context, it begins from a copy of the module's default. That is good isolation and bad diagnosis, because it means a leak in one worker thread is invisible from another. Coroutines are the harder case — they interleave *within* one thread, so an `await` in the middle of a block that has mutated the global context hands control to another coroutine that will run under your settings, and a coroutine that mutates the context can leave it changed for whatever resumes after it. This is the one place where `localcontext()` alone is not enough either: if you `await` inside the `with` block, other coroutines run inside your scoped context. Keep the block tight and free of awaits, or take the fully explicit route below. ### The explicit alternative A `decimal.Context` object is not only the ambient setting; it also exposes the arithmetic itself. `ctx = Context(prec=4)` followed by `ctx.divide(Decimal(1), Decimal(3))` computes under `ctx` with no reference to global state at all, and `ctx.create_decimal("1.23456789")` applies that context's precision at construction time — something the plain constructor never does. This style is verbose, which is why it is rare, but it is the right answer for a library that must not perturb its caller, and for computations that genuinely need a different precision while other work is in flight. ### Also global: the signal flags The same object accumulates flags — `Inexact`, `Rounded`, `Subnormal` and the rest — so if you ever inspect flags to prove a calculation was exact, you are reading shared state that some other code path may have set. Clear the flags immediately before the operation you are measuring, or do the whole check inside a `localcontext()` block so the flags you read are yours. Traps live there too: turning a trap on globally to catch a bug in one module changes exception behaviour everywhere in that thread. ### The rule to carry away Treat the decimal context the way you treat any process-wide setting: set it once at start-up if your whole application needs a non-default precision or rounding, and for anything narrower use `localcontext()` or an explicit `Context` object. Passing `rounding=` directly to a `quantize` call, where that is all you need, is better still — it changes no shared state at all.