Skip to main content

Module session

ignition_core

Module session 

Source
Expand description

The execution session — the ONE seam every auth/gateway-client resolution flows through (CORE-09).

Naming: THIS is an “execution session” — a resolved profile name plus the gateway client it builds. It is NOT a gateway session; the unrelated client::sessions family models the GATEWAY’s Designer/Perspective/Vision sessions. One word, two domains — the doc-comments everywhere else say “gateway session” when they mean that other thing.

Choreography (LOCKED — copied verbatim from the duplicated resolution sites this seam replaces: main.rs’s resolve_profile_context + resolve_gateway_api + resolve_headerless_api + rig_gateway_client, and the TUI’s context::resolve_from + rig_client_with):

  1. The IGNITION_URL env overlay is applied FIRST, scoped to the WOULD-BE selection (flag > active) — config::apply_env_overlay.
  2. THEN the selection resolves — config::resolve_selection (flag > active; unknown name → ProfileNotFound with the known profiles in the hint; nothing resolvable → NoActiveProfile, exactly what main.rs’s Ok(None) consumers do today).
  3. THEN the LOCKED secret chain (env tokens → keyring → basic pair) — config::resolve_secret over the one chain built below.

The client is built from the POST-OVERLAY profile — the research- locked precedence (flag > IGNITION_URL env > profile value) must hold at the construction site, not just in the config unit tests (main.rs:431’s contract, preserved here verbatim).

Three credential modes, one per real call-site family:

  • Session::resolve — REQUIRED credential (the authed reads: a missing secret is SecretUnavailable, exit 3 — never degraded).
  • Session::resolve_degraded — the credential DEGRADES to None when the chain exhausts (version / waits / doctor: these must run without a secret; every other credential error still propagates).
  • Session::for_url — headerless-BY-CONSTRUCTION rig clients: a caller-derived URL + explicit credential, no config read at all.

Concrete-with-deref (PLANNER DECISION, research open question 4): the handle is Arc<ReqwestGatewayApi>, not Arc<dyn GatewayApi> — the TUI’s workers/ClientHandle are concretely typed and Phase 8’s goal is construction-site unification, not handle-type churn; dyn-widening rides Phase 14 where MCP actually needs dyn. Deref feeds every existing free-fn action over &GatewayApi unchanged — the version() dyn precedent (actions/version.rs) and the rig_stream.rs cast precedent both keep working.

Redaction boundary UNCHANGED: [Secret::expose] stays confined to the client’s apply_auth header site (CORE-02’s grep-auditable rule). This module composes existing public config fns and introduces NO new exposure path.

IGNITION_PROFILE is deliberately NOT read here: the bin folds it into --profile in exactly one place (apply_env_defaults), so the flag this seam receives is already the effective selection.

Structs§

Session
One resolved execution context: a named profile and the gateway client built from its POST-OVERLAY state. Construct through the three constructors — never by struct literal (the fields are the resolved choreography’s output, not inputs).