refresh_shared_resolver(
config_path: Path,
) -> None| Name | Type | Description |
|---|---|---|
config_path* | Path | Path the caller just wrote. |
Make a committed write visible to the shared process resolver.
Only the default path is refreshed. get_config_resolver is keyed on
DEFAULT_CONFIG_PATH, so reloading it after a write to an override path
would re-read the real user config and the managed policy file - live
filesystem reads inside tests that passed a tmp_path - while leaving the
written path's own view stale anyway.
Refreshes every tier, managed policy included. The managed snapshot is fetched before the resolver takes its generation lock, then installed as an already-refreshed replacement. An in-app preference toggle therefore still picks up policy installed since startup without making ordinary event-loop config reads wait on remote I/O. Leaving the managed provider alone would let the user tier advance past the policy tier, which is the split-generation state the whole design exists to prevent.
Failures are logged rather than returned. The write already landed and was replaced into place; reporting a stale in-process view as a failed write sends the user to retry or hand-edit a file that is already correct.
Every failure, not just OSError: a reload can also raise ValueError
from the snapshot and resolved-value invariants, or RuntimeError from a
provider that produced no snapshot. Callers such as
model_config._save_toml_field invoke this from the success branch of
their own write and return bool, so anything escaping here surfaces as a
crash after the bytes are already on disk -- the exact outcome the
paragraph above says must not happen.