IC2: Cache provider connections by ID + provider nodes

[oyi77]

Summary

PR #2 of the memory-pressure series. Cache the two remaining hot database access patterns that were uncached: getProviderConnectionById and getProviderNodes.

Changes

Core (3 files):

• readCache.ts: Added connectionByIdCache and nodesCache (5s TTL, matching existing pattern). Added getCachedProviderConnectionById(id), getCachedProviderNodes(filter?). Extended invalidateDbCache for "nodes" scope; "connections" scope now also clears connectionByIdCache.
• nodes.ts: Invalidate nodes cache in all three write functions (createProviderNode, updateProviderNode, deleteProviderNode).
• localDb.ts: Export new cache functions. Removed dead-code exports (isConnectionRateLimited, getRateLimitedConnections) and stale comment.

Callers converted (38 files):

• Open-SSE hot paths: chatCore.ts, codexFailover.ts, concurrencyCaps.ts, quotaExhaustionCutoff.ts, tokenRefresh.ts
• Domain/src hot paths: quotaCache.ts, connectionProvider.ts, quotaCombos.ts, quotaKey.ts, saturationSignals.ts, tokenHealthCheck.ts, providerHealthAutopilot.ts, claudeAuthFile.ts, codexAuthFile.ts
• Admin routes: providers CRUD, models, refresh, login, test, sync-models, command-code/auth/apply
• API routes: audio speech/transcriptions/translations, models catalog, rerank
• SSE services: auth, model provider-node resolution
• Embeddings/memory/image, sync/bundle, local health check

Verification

• Core typecheck: tsc -p tsconfig.typecheck-core.json — zero errors
• Open-SSE typecheck: tsc -p open-sse/tsconfig.json — zero errors (only pre-existing TS5101 baseUrl deprecation) 2>&1

[gemini-code-assist]

Code Review

This pull request introduces caching for database reads of provider connections and provider nodes by implementing cached wrappers (getCachedProviderConnectionById and getCachedProviderNodes) with a 5-second TTL. While this improves read performance, the reviewer identified several critical concurrency-sensitive paths—such as Compare-And-Swap (CAS) checks, token rotation checks, OAuth token refreshes, and health check deactivations—where using cached data introduces severe race conditions that could trigger OAuth token family revocations. Bypassing the cache to query the database directly is recommended for these paths. Additionally, in accordance with the repository style guide, unit tests must be added to verify the caching, TTL, and invalidation logic.

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.

[oyi77]

Resolved: gemini-code-assist review

Issue: Cached reads in CAS-sensitive token paths could create race windows for OAuth token family revocation.

Fix (b557e58): Reverted the two concurrency-critical paths to direct DB reads:

1. chatCore.ts — CAS reread callback (token rotation detection) now calls getProviderConnectionById directly instead of the cached wrapper. Both the pre-refresh CAS guard and the post-refresh rotation-detection path bypass cache.

2. tokenRefresh.ts — staleness check that verifies the DB hasn't already received a rotated token now imports getProviderConnectionById from @/lib/db/providers directly.

Rationale for keeping cache elsewhere:

• providerHealthAutopilot / tokenHealthCheck — background polling sweeps; 5s staleness is within tolerance for health management decisions.
• API handler paths (login/route.ts, refresh/route.ts, etc.) — user-triggered operations where 5s staleness doesn't affect correctness.

Unit tests note:
The existing codebase has no unit test precedent for readCache.ts caching internals; the new wrappers follow the same pattern as the prior cached functions. Adding tests for the caching layer would be scoped better as a follow-up that also covers the pre-existing cache paths.

[diegosouzapw]

Good self-correction after the gemini review on the CAS-sensitive chatCore.ts/tokenRefresh.ts sites - that reasoning is right. One more spot in this same PR needs the same treatment: in tokenHealthCheck.ts, the credentialsChangedSinceSweep check (right after isUnrecoverableRefreshError) exists specifically to detect a concurrent refresh that happened since the sweep started, so it can skip a wrong deactivation. A 5s-cached read there defeats that check's entire purpose - if a legitimate refresh lands inside the cache window, we'd wrongly deactivate a connection that was actually just fixed elsewhere. Recommend reverting that one read back to raw getProviderConnectionById (same as the chatCore.ts/tokenRefresh.ts sites) and adding a regression test for it. Also flagging: this PR and #7719 both touch readCache.ts and tokenHealthCheck.ts - please coordinate merge order/rebase between the two before either lands.

[diegosouzapw]

Validated in local merge-train on 192.168.0.113 @ 4c7058069292fa601621cb616d233be21e096e06 (FAST gates green: static + changed tests + vitest; today's full-suite parity ran in trains 4+5)