Files
openchamber/packages/vscode/src/webviewCachedStateRetry.ts
T
Bohdan Triapitsyn cc0abad9af refactor(vscode): share the cached-state retry schedule across providers
The staggered re-send lived as three near-identical private methods in
the chat view, agent manager, and session editor providers. One helper
now owns the delays, the connected gate, and the replaced-target guard;
the providers keep thin wrappers over their own panel/view identity.
Also restores the package.json trailing newline the branch dropped.
2026-08-26 02:42:47 +03:00

32 lines
1.3 KiB
TypeScript

/**
* The webview only leaves its initial loading screen once it receives a
* `connectionStatus: connected` message. VS Code drops postMessage calls made
* before the webview's acquireVsCodeApi bridge is ready (common in
* code-server / slow or flaky networks), so a single send can be lost
* forever. Re-sending the cached state at staggered delays bounds the wait
* without needing a webview-side ack protocol; the payload is idempotent
* (connection status + window focus), so duplicate deliveries are harmless.
*/
const CACHED_STATE_RETRY_DELAYS_MS = [500, 1500, 3500, 7000, 12000, 20000];
export function scheduleCachedStateRetries<Target>(input: {
/** The panel/view the retries belong to. */
target: Target | undefined;
/** Reads the provider's CURRENT panel/view, so a replaced target stops its stale retries. */
getCurrent: () => Target | undefined;
/** Retries only make sense for the connected transition. */
isConnected: () => boolean;
/** Re-sends the provider's cached state. */
send: () => void;
}): void {
if (!input.isConnected()) return;
const target = input.target;
if (!target) return;
for (const delayMs of CACHED_STATE_RETRY_DELAYS_MS) {
setTimeout(() => {
if (input.getCurrent() !== target) return;
input.send();
}, delayMs);
}
}