Skip to content

sdk: config slot for init-stored module config #67

Description

@mfw78

nexum_sdk::config covers lookup and parsing (get_required, get_optional, ConfigError, fixed-point helpers) but not storage: every module that parses [config] in init and reads it in later dispatches hand-rolls the same static RwLock<Option<T>>, a store_config, a typed not-initialised refusal, and a test-only guard/clear pair. Two consumers already duplicate it verbatim (cow-venue's AdapterConfig, twap-monitor's KeeperConfig) and every future configured module adds another copy.

Why

The supervisor's lifecycle makes the pattern universal: call_init runs with the manifest config on every (re)instantiation against a fresh Store, so instance-memory storage re-seeded by init is the correct home for operator wiring, and each module reinventing the slot invites drift (poison handling, refusal type, test-isolation shape). The lookup half already lives in the SDK; the storage half should sit beside it.

Scope

  • config::Slot<T> (name open): const fn new, store(T), get() -> Result<T, ConfigError> (or a dedicated not-initialised variant), poison-tolerant via PoisonError::into_inner.
  • cfg(test) helpers: clear and a serialising guard, so refusal tests are runner-independent (nextest process-per-test and plain libtest both pass).
  • Rustdoc states the lifecycle contract: init re-seeds on every (re)instantiation; the slot is instance memory, never persisted.
  • Migrate consumers to get_required/ConfigError opportunistically when they adopt the slot; not part of this change.

Done when

  • A module can replace its hand-rolled static with the SDK slot and delete its guard/clear test scaffolding.
  • The not-initialised read is a typed error usable in a Fault boundary conversion.
  • Tests cover store/get, the refusal, and threaded-runner isolation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:sdkGuest-side ergonomics: nexum-sdk, nexum-sdk-test, module macrosenhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions