fix(loading): debounce selector search, fix two row-cache snapshots, and move Vertex refresh to the app

[waleedlatif1]

Summary

Three fixes an audit of the recent loading-pattern work turned up. Independent; each is the minimal change.

Selector search hit the provider on every keystroke. Adding search to the CloudWatch selector keys was the right fix for a real cache collision — a filtered result was being served under the unfiltered key — but it exposed a missing debounce. Each character minted a new key, so the open dropdown emptied and a fresh provider call went out; typing a dozen characters meant a dozen sequential calls against a rate-limited API. The search is now debounced with the shared SEARCH_DEBOUNCE_MS before it enters the key, matching the seven provider families that already do this, and the list keeps its previous options while the next result loads. Only the query sees the debounced value; the input stays instant.

Two row-cache snapshots still walked the shared prefix. patchCachedRows and snapshotAndMutateRows moved to tableKeys.infiniteRowsRoot because find entries hang off the same parent with a different shape, but the cancelQueries/getQueriesData pairs in the two row-update mutations did not. They only read, so nothing threw — but a failed update restored stale search matches over fresh ones and refreshed their timestamp, so the cache would not self-correct until the entry went stale.

Vertex OAuth tokens were refreshed inside the worker. An OAuth refresh needs the provider's client id and secret, read through requireOAuthClientCapability, which throws when they are absent. Only the app container loads them; workflow execution runs in a Trigger.dev worker that does not. The token now comes from the app through the same route tool credentials use, added as a small shared helper rather than a second inline copy. Authorization is unchanged and still runs first — the workspace binding and member checks happen before any token is requested. The service-account branch needs no client config and stays in-process.

Pre-existing rather than a regression, and masked while a stored token is still valid, which is why it had not surfaced.

Type of Change

• Bug fix

Testing

1,247 tests pass across the touched areas. New coverage for the Vertex OAuth path asserts the token is fetched from the app and that authorization runs first; verified it fails against the pre-fix code and passes after.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 13, 2026 8:42pm

[cursor]

PR Summary

Medium Risk
Vertex credential resolution now depends on an internal app HTTP call from workers; misconfiguration or auth bugs could break expired OAuth Vertex runs, though authorization order is unchanged.

Overview
Selector combobox now debounces search with SEARCH_DEBOUNCE_MS before it becomes part of the selector query key, so rate-limited providers aren’t hit on every keystroke; clearing the search still updates the query immediately.

Table row updates cancel and read React Query data under tableKeys.infiniteRowsRoot instead of rowsRoot, matching how infinite row caches are patched so failed updates don’t restore stale filtered rows.

Vertex OAuth in the Trigger.dev worker no longer refreshes tokens in-process (workers lack OAuth client config). A shared fetchCredentialAccessToken helper calls the app’s /api/auth/oauth/token route after the same authorization checks; agent, evaluator, and router pass workflowId into resolveVertexCredential. Service-account credentials still resolve locally.

Realtime test for Redis reader backoff uses vi.waitFor instead of fixed sleeps so streak/idle timing assertions are reliable on slow CI.

^{Reviewed by Cursor Bugbot for commit 80ec0ee. Configure here.}

[greptile-apps]

Greptile Summary

The PR debounces provider-backed selector searches, narrows optimistic table-row snapshots to infinite-row caches, and resolves Vertex OAuth tokens through the app runtime.

• Keeps selector input responsive while delaying provider queries and removes cross-context option retention.
• Prevents failed row updates from restoring incompatible search-result caches.
• Moves Vertex OAuth token refresh across the app/worker runtime boundary while preserving authorization checks.
• Makes realtime retry tests wait for observed state transitions rather than fixed timing windows.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/components/sub-block/components/selector-combobox/selector-combobox.tsx	Debounces the normalized provider search value while preserving immediate input and clear behavior.
apps/sim/hooks/queries/tables.ts	Restricts optimistic update snapshots and cancellation to infinite-row query entries.
apps/sim/executor/utils/credential-token.ts	Adds an authenticated app-route helper for retrieving refreshed credential access tokens.
apps/sim/executor/utils/vertex-credential.ts	Preserves local service-account resolution while routing OAuth token retrieval through the app.
apps/realtime/src/handlers/file-doc-store.test.ts	Replaces timing-sensitive sleeps with state-based waits in reader recovery coverage.

_{Reviews (4): Last reviewed commit: "fix(realtime): wait for the streak-reset..." | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[waleedlatif1]

Fixed the @sim/realtime failure — it was a flaky arrange, and worth explaining because the number was misleading.

expected 2181 to be less than 1000 looks like a stalled short sleep, but 2181ms lands squarely in the carried-over backoff band (2000ms ±20% ⇒ 1600–2400). A stalled 500ms sleep does not land there. The streak simply had not been reset, so the assertion was correctly measuring a delay the test never meant to produce.

The cause is the arrange phase, not the assertion. It built the failure streak with sleep(800) and then waited sleep(1000) for an idle read to land and end the streak. Both are wall-clock guesses: on a loaded runner the window can close with the pending backoff still outstanding, so no idle read lands, the streak survives, and the next blip legitimately opens partway up the curve. That run also logged three sticky-disk mount failures, so it was a degraded machine.

Both sleeps are now vi.waitFor on the actual precondition — two failed reads for the streak, then one read landing after the reader reopens (xRead only throws while closed, so the next read to arrive is the idle one). The assertion is unchanged; it just now runs against the state it assumes.

Verified 8/8 locally including three runs under 4-way CPU contention, plus the full realtime suite (279 tests).

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 80ec0ee. Configure here.}