Skip to content

fix(orchestrator): lazy threadpool imports for pyodide consumers (sy-2wa)#460

Open
openclaw-dv wants to merge 1 commit into
mainfrom
polecat/garnet-mp3ex3kk
Open

fix(orchestrator): lazy threadpool imports for pyodide consumers (sy-2wa)#460
openclaw-dv wants to merge 1 commit into
mainfrom
polecat/garnet-mp3ex3kk

Conversation

@openclaw-dv
Copy link
Copy Markdown
Collaborator

Summary

Moves import threading + from concurrent.futures import ThreadPoolExecutor, as_completed from module top to function-local imports in orchestrator,
synthesis, and perturbation. The synth_panel.ensemble load chain is now
fully threadpool-free at module load time, unblocking Cloudflare Python
Workers / pyodide consumers (boardroom DECISION-skill officers) where
ThreadPoolExecutor exists as a stub but .submit() silently hangs.

Why

pyodide_safe_mode (sy-huo) and the trafilatura → [full] extra move (sy-v8z)
fixed runtime + install-time dep cliffs, but import synth_panel.ensemble
still pulled concurrent.futures at module-load time. Under pyodide the
import succeeds but the executor is a no-op stub — a latent footgun for any
caller that didn't pass judge_enabled=False / llm_client=.... This
release closes the remaining import-time gap.

Changes

  • src/synth_panel/orchestrator.py, src/synth_panel/synthesis.py, src/synth_panel/perturbation.py: move threading + concurrent.futures imports inside the functions that actually spawn threads.
  • tests/test_threadpool_lazy_import.py: subprocess-based load-chain hygiene assertions —
    1. concurrent.futures stays out of sys.modules after a fresh ensemble import,
    2. ensemble loads cleanly under a poisoned concurrent.futures module,
    3. ThreadPoolExecutor / as_completed are never bound at the top of orchestrator / synthesis / perturbation.
  • Version bump 1.4.x → 1.5.0; server-card.json + site renders refreshed.

Compatibility

No public-API change. Every existing call site keeps working. Pyodide
consumers that were forced into judge_enabled=False to avoid the module-load
crash can now also use other ensemble entry points safely.

Test plan

  • tests/test_threadpool_lazy_import.py pins the contract via subprocess + meta-path poisoning.
  • GitHub CI runs the full suite on this PR.

References

…2wa)

Move `import threading` + `from concurrent.futures import ThreadPoolExecutor,
as_completed` from module top to function-local imports in orchestrator,
synthesis, and perturbation. The `synth_panel.ensemble` load chain is now
fully threadpool-free at module load time, unblocking Cloudflare Python
Workers / pyodide consumers (boardroom DECISION-skill officers) where
ThreadPoolExecutor exists as a stub but `.submit()` silently hangs.

Adds tests/test_threadpool_lazy_import.py — subprocess-based load-chain
hygiene assertions: (1) concurrent.futures stays out of sys.modules after
a fresh ensemble import, (2) ensemble loads cleanly under a poisoned
concurrent.futures module, (3) ThreadPoolExecutor/as_completed are never
bound at the top of orchestrator/synthesis/perturbation.

Bumps __version__ to 1.5.0 + refreshes server-card.json / site renders.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant