fix(HYBIM-787): clear bridged GALILEO_* env vars on reset()

[adityamehra]

Summary

• Bug: After the first SplunkAOConfig.get() call, every GALILEO_* env var is permanently written to os.environ. When reset() is called, galileo-core's reset only clears the config object's in-memory fields — it never removes those env vars. On the next get(), the bridge sees GALILEO_API_KEY "already set" and skips the copy, so galileo-core silently re-authenticates with the stale original credentials.
• Impact: Credential/project rotation within a long-lived process (notebooks, test suites, re-init flows) silently authenticates against the wrong target. Not caught by unit tests because _check_auth_config reads SPLUNK_AO_* directly.
• Fix: Extract _BRIDGE to module level so reset() can reference it, then have SplunkAOConfig.reset() pop() every GALILEO_* key before calling super().reset(). The next get() re-bridges cleanly from the current SPLUNK_AO_* values.

Closes HYBIM-787.

Changes

• src/splunk_ao/config.py: Extract _BRIDGE to module level; extend SplunkAOConfig.reset() to clear bridged GALILEO_* env vars.
• tests/test_config.py: Add three regression tests covering the stale-bridge scenario.

Test plan

• test_reset_clears_bridged_galileo_env_vars — reset() removes every GALILEO_* key the bridge may have written
• test_bridge_picks_up_new_credential_after_reset — full get() → reset() → credential rotation → get() flow uses the new key
• test_reset_removes_all_bridgeable_galileo_vars — documents the trade-off that reset() owns all bridge GALILEO_* keys
• All existing test_config.py tests pass (45 total)
• Main suite: 1820 passed, 11 skipped
• splunk-ao-adk: 252 passed
• splunk-ao-a2a: 67 passed

Made with Cursor

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: approve — Fix correctly clears stale bridged env vars and is well-tested; one design asymmetry worth noting but non-blocking given the documented trade-off.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• tests/test_config.py:151-158: test_bridge_picks_up_new_credential_after_reset writes GALILEO_API_KEY directly to os.environ and only pops it on the final line. If any earlier assertion fails, the manual cleanup is skipped and GALILEO_API_KEY leaks into subsequent tests. Consider wrapping the direct os.environ writes in a patch.dict(..., clear=False) block (as the other bridge tests do) so cleanup is guaranteed regardless of assertion outcome.

[fercor-cisco]

🟡 minor (design): reset() unconditionally pops every GALILEO_* key in _BRIDGE, but _bridge_env_vars() deliberately preserves user-set GALILEO_* values ("explicit GALILEO_* overrides win"). So a user who sets GALILEO_API_KEY directly — without a SPLUNK_AO_* equivalent — will have it silently deleted by reset(), and the next get() will fail with no credential to re-bridge. This breaks the documented override invariant. The PR acknowledges this as a trade-off ("the bridge owns all GALILEO_* keys"), but the safer, symmetric fix is to only clear keys the bridge actually wrote: have _bridge_env_vars() record the keys it set (e.g. a class-level set) and have reset() pop only those. That fixes the stale-bridge bug without touching user-provided overrides. Worth confirming the "no consumer sets GALILEO_* directly" assumption holds for downstream SDKs (splunk-ao-adk / a2a) before relying on it.

🤖 Generated by the Astra agent

[fercor-cisco]

I think the two nits brought up by Claude are acceptable.