SCAL-319970: Multi-org support (list_orgs / switch_org) on shared mcp-auth

[rohitthughtspot]

Summary

Adds multi-org support to the ThoughtSpot MCP server on top of the shared @thoughtspot/mcp-auth auth layer (post-#165 extraction):

• list_orgs / switch_org v2 tools — list the user's orgs and switch the active org mid-session.
• OrgService — user-scoped org listing (session/orgs) + org-scoped token minting (auth/token/fetch?org_identifier=).
• UserTokenStoreSQLite DO — per-user active org + org token + keep-warm cluster token (11h refresh alarm; 14-day idle abandonment). Keyed by hash(refreshToken) so it's shared across the client's fan-out.
• Org overlay in MCPServer: per-request active-org reload, org-scoped bearer (fail-closed — never the global token on a data call), reactive 401 re-mint (mint-first/atomic), org-tagged datasource cache.

Backward compatibility

Gated on OAuth + Orgs-enabled + v2 + a multi-org grant (a refresh token in the grant, decided once in postInit). A pre-multi-org grant (no refresh token) keeps the exact old behavior — no org tools, no overlay, its login token — until the user re-authenticates. Bearer/token and v1 sessions are unaffected.

Dependency

Requires @thoughtspot/mcp-auth@^2.0.0, which adds the extendGrantProps hook that carries the refresh token / expiry into the OAuth grant (needed for keep-warm). That must be published before CI is green.

Testing

• Unit/integration: 627 passing (org tools/gate, isolation, fan-out last-write-wins, F2a mint-first re-mint, org-tagged cache, keep-warm lifecycle, backward-compat gate, listOrgs mapping edges, switch_org 4xx/5xx).
• Live E2E on a test worker: list/switch/bad-org-no-op, cross-org data isolation (disjoint datasets), keep-warm refresh cycle + idle abandonment verified.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces multi-org support and token keep-warm capabilities to the ThoughtSpot MCP server, adding a new UserTokenStoreSQLite Durable Object to manage active org states and keep-warm tokens, alongside new list_orgs and switch_org tools. The code review highlights three key areas for improvement: addressing a potential race condition in refreshTokenStore by using a transaction, avoiding redundant writes in active-org updates, and fixing a fallback bug in loadOrSeedWarmToken where an expired stored token could be incorrectly preferred over a fresh context token.

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]

There is a potential race condition where a user re-authenticates and re-seeds the token store (via POST /token-store) while an alarm-triggered refreshTokenStore is awaiting the fetch call. When the fetch completes, refreshTokenStore could overwrite the newly seeded token store with the old refreshed credentials. To prevent this, we should perform the read and write operations within a transaction to ensure atomicity, and abort the write if the refresh token has changed.

await this.state.storage.transaction(async (tx) => {
	const currentStore = await tx.get<TokenStore>(TOKEN_STORE_KEY);
	if (!currentStore || currentStore.refreshToken !== store.refreshToken) {
		console.log("Token store was updated concurrently; aborting write");
		return;
	}
	await tx.put<TokenStore>(TOKEN_STORE_KEY, {
		accessToken,
		refreshToken,
		instanceUrl: store.instanceUrl,
		expiresAt: typeof newExpiresAt === "number" ? newExpiresAt : store.expiresAt,
		lastSeenAt: store.lastSeenAt,
	});
});

References

1. Operations that involve reading and then writing to storage, especially when multiple clients might access the same data, should be performed within a transaction to ensure atomicity and prevent race conditions or data inconsistencies, unless the system design explicitly guarantees single-client access.

[gemini-code-assist]

When body.orgToken is not provided, the code always writes body.activeOrgId to ACTIVE_ORG_KEY even if it is identical to the previousOrgId. We can avoid this redundant write by only writing and deleting when the active org ID actually changes. Since this involves reading and then writing to storage, it should be performed within a transaction to ensure atomicity and prevent race conditions.

await this.state.storage.transaction(async (tx) => {
	const previousOrgId = await tx.get<string>(ACTIVE_ORG_KEY);
	if (previousOrgId !== body.activeOrgId) {
		await tx.put<string>(ACTIVE_ORG_KEY, body.activeOrgId);
		await tx.delete(ORG_TOKEN_KEY);
	}
});

References

1. Operations that involve reading and then writing to storage, especially when multiple clients might access the same data, should be performed within a transaction to ensure atomicity and prevent race conditions or data inconsistencies, unless the system design explicitly guarantees single-client access.

[gemini-code-assist]

In loadOrSeedWarmToken, if the stored token is expired and there is no refresh token to re-seed with, the fallback will still prefer the expired store.accessToken over the potentially fresh accessToken from this.ctx.props. We should check storedExpired before falling back to store.accessToken.

Suggested change

	// No refresh token to re-seed with: use whatever we have.
	this.warmGlobalToken = store.accessToken ?? accessToken;
	this.warmGlobalToken = (store.accessToken && !storedExpired) ? store.accessToken : accessToken;