Remove task-worker multiprocessing#14754
Merged
rtibbles merged 1 commit intoJun 4, 2026
Merged
Conversation
7286756 to
ca351c4
Compare
Contributor
Build Artifacts
Smoke test screenshot |
The in-process multiprocessing option for async task workers (USE_WORKER_MULTIPROCESSING) has never been production-ready and its parametrized test fixture is a source of flaky CI. Default has been False for the life of the option. The worker is now thread-only. Deployers who want CPU isolation can run `kolibri services` as a separate OS process. Changes: - Delete kolibri/utils/multiprocessing_compat.py. - Worker uses ThreadPoolExecutor directly; drop the log_queue parameter from execute_job, execute_job_with_python_worker, Worker, initialize_workers, and ServicesPlugin.START. - utils.py: use threading.local / threading.Event directly; drop the dead ProcessPoolExecutor branch in fd_safe_executor. - logger.py: switch the queue listener to stdlib queue.Queue; drop the pickle-safety and queue.close()/join_thread() branches that only mattered under multiprocessing; delete the unused setup_worker_logging bootstrap. The queue-based logging machinery itself stays (still useful on Windows). - options.py: remove the USE_WORKER_MULTIPROCESSING schema entry and its now-orphaned multiprocess_bool validator. ConfigObj silently drops unknown keys, so existing options.ini files won't fail to load. - Delete the parametrized mock_compat fixture in kolibri/core/tasks/test/taskrunner/conftest.py. - Trim Job.task docstring to drop the multiprocessing reference.
8cbcf24 to
67cbb9a
Compare
67cbb9a to
bd5f57c
Compare
bjester
approved these changes
Jun 4, 2026
Member
bjester
left a comment
There was a problem hiding this comment.
As a removal, the changes appear straightfoward and correct
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
USE_WORKER_MULTIPROCESSINGhas defaulted toFalsefor the lifetime of the option, the multiprocessing branches have never been production-ready, and the parametrizedmock_compatfixture is a recurring source of flaky tests.kolibri servicesin its own process.References
Reviewer guidance
LogPluginno longer attachesbus.log_queue. Worth confirming no out-of-tree plugin reads it off the magicbus.options.inifiles in the wild that still setUSE_WORKER_MULTIPROCESSING = Truecontinue to load — ConfigObj silently drops unknown keys. The setting just stops doing anything.AI usage
Claude Code (Opus 4.7) handled this end-to-end: brainstormed the spec with me, wrote the implementation plan, dispatched subagents per plan task, and ran a self-review pass over the working tree against the spec. I reviewed the spec and plan before execution, deleted the unused conftest placeholder, and approved the commit structure.