Repair session info on demand + fix callTool token reconcile

[rohitthughtspot]

Problem

After a cold-start reconnect (~24h, once the frozen props access token has expired), list_orgs/switch_org disappear and datasource-discovery gating breaks — even though the keep-warm token is valid.

Cause

sessionInfo is fetched once at init via getSessionInfo(), which runs before postInit reconciles the keep-warm global token from the DO. On that reconnect the fetch authenticates with the dead frozen props token, fails, and leaves sessionInfo null for the instance lifetime. Org-tool visibility and datasource gating read sessionInfo, so they mis-gate — while the DO still holds a valid token (data tool calls, which reconcile it at call time, keep working).

Fix

• ensureSessionInfo() — refetch session info when it's null, called at the top of listTools()/callTool(). By then postInit has loaded the kept-warm token, so the refetch authenticates with it. No-op (no network call) once populated — happy path unaffected.
• callTool per-call reconcile keyed on !this.activeOrgToken — so a data call always gets a freshly reconciled global token when no org token drives it (covers non-orgs clusters and the no-active-org case).

Test

Regression test reproduces the failure (init getSessionInfo fails on an expired props token; DO holds a valid token) and asserts the repair restores sessionInfo and the org tools. Verified it fails without the fix. Server suites pass.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a lazy session info repair mechanism (ensureSessionInfo) to handle cases where the initial, init-time getSessionInfo call fails due to an expired token. This ensures that subsequent tool list and call requests can repair the session info using the kept-warm token. Feedback on these changes highlights two key issues: first, when sessionInfo is repaired on-demand, the active org initialization logic does not run, leaving the session unscoped to the user's default active org; second, concurrent calls to ensureSessionInfo can cause race conditions and duplicate trackers, which should be guarded against using a promise.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If the init-time getSessionInfo fails (e.g., due to an expired token), postInit() skips defaulting this.activeOrgId to this.sessionInfo.currentOrgId. When ensureSessionInfo() later repairs this.sessionInfo during a tool call, this.activeOrgId remains undefined because the default active org initialization logic only ran in postInit(). This means the session will continue to run without being scoped to the user's default active org (no x-thoughtspot-orgs header or org-scoped token), which can lead to data discrepancies or errors. We should run the active org initialization logic inline when sessionInfo is repaired.

		// Repair session info if the init-time fetch failed, so the org-tools gate
		// below (and getActiveToken's token selection) act on the real state.
		const hadSessionInfo = !!this.sessionInfo;
		await this.ensureSessionInfo();
		if (!hadSessionInfo && this.sessionInfo && this.areOrgToolsAvailable()) {
			await this.loadActiveOrg();
			if (!this.activeOrgId) {
				const currentOrgId =
					this.sessionInfo.currentOrgId != null
						? String(this.sessionInfo.currentOrgId)
						: undefined;
				if (currentOrgId) {
					this.activeOrgId = currentOrgId;
				}
			}
			if (this.activeOrgId && !this.activeOrgToken) {
				try {
					await this.forceRecreateActiveOrgToken(recorder);
				} catch (error) {
					console.error("Failed to mint active org token after repair:", error);
				}
			}
		}

[mouryabalabhadra]

@copilot review pr

[Copilot]

@copilot review pr

Reviewed the PR changes and I don’t see any high-signal bugs or security issues to address right now. CI is currently green on the latest pull_request run; earlier failures on this branch were from a transient Coveralls 504 error.