Summary
Interactive and shell completion evaluate the routing graph at a moment that can differ from committed execution, so the set of active (module-gated) routes — and therefore the suggestions — can diverge from what actually runs. This surfaced during the review of #50 (interactive option-name completion) but is a routing-graph/cache concern independent of option completion, so it is split out here.
Two related, partly-opposing aspects:
1. Completion does not apply the invocation's parsed globals to module presence
When a module's presence depends on a global option (e.g. a module gated on --env prod), completing --env prod secret -- does not offer secret's options, because module presence during completion is evaluated without the line's globals applied. Execution applies the globals first (GlobalOptionParser → snapshot update) and resolves the gated module correctly.
Expected: completion should evaluate module presence under the globals parsed from the current line, so suggestions match what the committed line would run.
2. Completion should read (but still not write) the durable routing cache
PR #50 made completion compute a fresh graph and bypass the durable cache entirely (to avoid poisoning it — that half is fixed). But bypassing the read makes completion observe module-presence changes that committed execution deliberately ignores until InvalidateRouting() (e.g. a session-state login/logout without invalidation). Completion can then suggest commands the next committed line resolves against the still-cached graph and rejects.
Expected: completion reads the durable cache when it matches the current channel/version (so it matches execution's committed view), and only avoids writing a provisional graph.
These two pull in opposite directions (apply-the-line's-globals = fresher; match-execution's-cached-view = as-committed) and need a considered design — likely a completion-scoped graph evaluated under the parsed globals, kept out of the durable cache, while still reflecting the last committed invalidation state.
Context
Not doing yet
This is intentionally out of scope for #50 (option-name completion). Filing so the graph-under-globals semantics get their own design + review.
🤖 Generated with Claude Code
https://claude.ai/code/session_01H1Afor6vpDgWBQqTb95Sjd
Summary
Interactive and shell completion evaluate the routing graph at a moment that can differ from committed execution, so the set of active (module-gated) routes — and therefore the suggestions — can diverge from what actually runs. This surfaced during the review of #50 (interactive option-name completion) but is a routing-graph/cache concern independent of option completion, so it is split out here.
Two related, partly-opposing aspects:
1. Completion does not apply the invocation's parsed globals to module presence
When a module's presence depends on a global option (e.g. a module gated on
--env prod), completing--env prod secret --does not offersecret's options, because module presence during completion is evaluated without the line's globals applied. Execution applies the globals first (GlobalOptionParser→ snapshot update) and resolves the gated module correctly.Expected: completion should evaluate module presence under the globals parsed from the current line, so suggestions match what the committed line would run.
2. Completion should read (but still not write) the durable routing cache
PR #50 made completion compute a fresh graph and bypass the durable cache entirely (to avoid poisoning it — that half is fixed). But bypassing the read makes completion observe module-presence changes that committed execution deliberately ignores until
InvalidateRouting()(e.g. a session-state login/logout without invalidation). Completion can then suggest commands the next committed line resolves against the still-cached graph and rejects.Expected: completion reads the durable cache when it matches the current channel/version (so it matches execution's committed view), and only avoids writing a provisional graph.
These two pull in opposite directions (apply-the-line's-globals = fresher; match-execution's-cached-view = as-committed) and need a considered design — likely a completion-scoped graph evaluated under the parsed globals, kept out of the durable cache, while still reflecting the last committed invalidation state.
Context
AutocompleteEngine.csgraph resolution).ResolveActiveRoutingGraph(useDurableCache: false).Not doing yet
This is intentionally out of scope for #50 (option-name completion). Filing so the graph-under-globals semantics get their own design + review.
🤖 Generated with Claude Code
https://claude.ai/code/session_01H1Afor6vpDgWBQqTb95Sjd