zylon-ai/private-gpt · error · ValueError
Unknown scheduler.tools.mode: {mode}
Error message
Unknown scheduler.tools.mode: {mode} What it means
ValueError raised by ToolSchedulerFactory.get when settings.scheduler.tools.mode does not match any key in the _TOOL_SCHEDULERS provider map. The factory looks up the mode string and refuses to proceed with an unknown scheduler backend.
Source
Thrown at private_gpt/components/tools/tool_scheduler.py:293
register_tool_scheduler("celery", CeleryToolScheduler)
@singleton
class ToolSchedulerFactory:
@inject
def __init__(self, settings: Settings, injector: Injector) -> None:
self._settings = settings
self._injector = injector
self._scheduler: BaseToolScheduler | None = None
def get(self) -> BaseToolScheduler:
if self._scheduler is None:
mode = self._settings.scheduler.tools.mode
provider = _TOOL_SCHEDULERS.get(mode)
if provider is None:
raise ValueError(f"Unknown scheduler.tools.mode: {mode}")
self._scheduler = (
self._injector.get(provider)
if isinstance(provider, type)
else provider(self._injector)
)
return self._scheduler
View on GitHub (pinned to 4a030776a3)
Solutions
- Check _TOOL_SCHEDULERS keys in private_gpt/components/tools/tool_scheduler.py and set scheduler.tools.mode to one of them
- Inspect effective settings (env overrides included) to find the invalid value: print settings.scheduler.tools.mode
- After upgrading, re-validate all scheduler.* settings against the current version's settings schema
Example fix
# before (settings.yaml)
scheduler:
tools:
mode: inproc # typo / unknown
# after
scheduler:
tools:
mode: in_process # a key present in _TOOL_SCHEDULERS Defensive patterns
Strategy: validation
Validate before calling
from private_gpt.components.tools.tool_scheduler import _TOOL_SCHEDULERS
mode = settings.scheduler.tools.mode
assert mode in _TOOL_SCHEDULERS, (
f"scheduler.tools.mode must be one of {sorted(_TOOL_SCHEDULERS)}, got {mode!r}"
) Try / catch
try:
scheduler = factory.get()
except ValueError as e:
if "Unknown scheduler.tools.mode" in str(e):
# fix the setting and restart; do not retry with the same value
raise Prevention
- Validate all scheduler.* settings at startup rather than at first scheduler use
- Pin docs/config templates to the version in use; re-check mode names after upgrades
- Fail fast in deploy pipelines with an explicit settings validation step
When it happens
Trigger: Setting scheduler.tools.mode in settings (env var / config file) to a value not registered in _TOOL_SCHEDULERS (e.g. typo like 'inprocess' vs 'in_process', or a mode removed in a version upgrade). Raised on first scheduler access, i.e. lazily at runtime, not at startup.
Common situations: Copying a mode name from outdated docs; upgrading the library where scheduler modes were renamed/removed; stale environment variable overriding the config file.
Related errors
- Unsupported scheduler.chat.mode={self.scheduler.chat.mode!r}
- Unsupported scheduler.tools.mode={self.scheduler.tools.mode!
- Unknown scheduler.chat.mode: {mode}
- scheduler.tools.mode={self.scheduler.tools.mode!r} requires
- scheduler.chat.mode={self.scheduler.chat.mode!r} requires st
AI-assisted analysis of zylon-ai/private-gpt@4a030776a3 (2026-08-15).
Data as JSON: /api/errors/497fb4a5319fb542.
Report an issue: GitHub.