Add Config singleton cache (scoped first cut of #8)#70
Open
ff225 wants to merge 1 commit into
Open
Conversation
Config loading was scattered: several call sites (edge_initialization.py, log.py, run_edge.py) re-read and re-validated settings.yaml on every call instead of caching, unlike request_handler.py's ad-hoc _settings_cache. Config.get_server()/get_client() wrap the existing sciot.config loaders with a per-path cache, giving a single access point without touching the in-flight request_handler.py/http_server.py/message_data.py PRs.
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
Partial fix for #8 — scoped to avoid conflicting with the in-flight PRs that touch
request_handler.py,http_server.py, andmessage_data.py.Investigated the current state first:
src/sciot/config.pyalready has solid YAML loading, env-var overrides, and full schema validation — the "prerequisite for modularity" work the issue's own comment worried about is largely done. The real gap was just caching/access: every call site independently calledload_server_config/load_client_configand re-parsed + re-validated the YAML on every call, exceptrequest_handler.py's own ad-hoc_settings_cache.Added
src/common/config.py::Config, a small singleton-style cache withConfig.get_server(path=None)/Config.get_client(path=None)wrapping the existingsciot.configloaders, caching per resolved path. Migrated three call sites that don't touch the in-flight-PR files:src/server/edge/edge_initialization.py(load_delay_config,__main__block)src/server/logger/log.py(configure_logger_from_settings)src/server/edge/run_edge.py(main)Scope notes
Left untouched on purpose:
src/server/communication/request_handler.py— already has its own_settings_cache, and is being actively modified by PR Add device/edge CPU, network latency, switch penalty to offloading_decisions #68/Fix offloading_decision_summary.py to read all split segments #69.src/client/python/http_client.py— loads client config eagerly at import time with its ownCONFIG_PATHenv override; migrating that is riskier and out of scope for this first cut.src/sciot/cli.py— one-shot config-validate invocations, no repeated-read problem to fix.A follow-up can migrate
request_handler.py/http_client.pytoConfigonce the in-flight PRs land, and/or foldsciot.config's standalone functions behindConfigentirely if that's the desired end state — leaving that as a separate, smaller PR rather than bundling it here.Test plan
tests/unit/test_common_config.py: per-path caching (single parse across repeated calls),force_reload,reset(), independent caching across different paths, default-path resolution for both server and client configs.uv run pytest tests/unit/test_common_config.py -q— 8 passedtests/unit, integration subset, mqtt, offloading_algo) — 211 passed, 1 skipped, no regressionsuv run ruff checkon all changed files — cleanRelated: closed #3 separately (stale — the "redundant JSON parsing for offloading history" it described was already fixed by existing class-level caches in
offloading_algo.py/request_handler.py).