Repository navigation
perf(sign-in): restore a saved sign-in over CDP instead of agent-browser's state load - #11
Merged
Merged
Conversation
…ser's state load v0.84.2's timings put a walk's sign-in restore at 3.0 to 3.2 s of its 6.5 to 8.4 s setup. agent-browser's `state load` (v0.38.1, unchanged through v0.39.1) sets the cookies, then for every origin with storage navigates the tab to the product's real root, sleeps a fixed 500 ms and writes one key per evaluate; the product then loads a second time on open. - `browser-state-restore.mjs` restores the whole state itself, the way it already restored IndexedDB and the way Playwright restores a storage state: one `Network.setCookies` (the fields `state load` sent, no partition key), then each origin with localStorage, sessionStorage or IndexedDB is navigated to with the request answered by an empty document from Fetch interception, and its storages are written in one evaluate. Nothing reaches the product before it opens. - Every lane that called `state load` uses it: the product open shared by Suite walks and Activities, the sign-in check and the idle sign-in browser. A state that cannot be read or whose cookies the browser refuses throws as `state load` did; storage that did not go back is named in the existing restore outcome. - The Activity lane's `restoreStatus` (from a `state load` reply field v0.38.1 never sends) is gone with it. Checks: typecheck, lint (biome + discipline), pi lane. Local stack: signed-in Verifications on all three eval products (passed, a fault run failed correctly) and two signed-in walks (completed); those products sign in with cookies only, so a headless Chromium check covered the storages: cookies, localStorage (including quotes and line breaks) and sessionStorage were all there when the page opened in the same tab, the product server saw no request before that open, and the restore took 157 ms. Claude-Session: https://claude.ai/code/session_01QXmSJBFujofueuHrdm6TdA
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
v0.84.2's timings put a walk's sign-in restore at 3.0 to 3.2 s of its 6.5 to 8.4 s setup. agent-browser's
state load(v0.38.1, unchanged through v0.39.1) sets the cookies, then for every origin with storage navigatesthe tab to the product's real root, sleeps a fixed 500 ms and writes one key per evaluate; the product then loads a
second time on open.
browser-state-restore.mjsrestores the whole state itself, the way it already restored IndexedDB and the wayPlaywright restores a storage state: one
Network.setCookies(the fieldsstate loadsent, no partition key),then each origin with localStorage, sessionStorage or IndexedDB is navigated to with the request answered by an
empty document from Fetch interception, and its storages are written in one evaluate. Nothing reaches the
product before it opens.
state loaduses it: the product open shared by Suite walks and Activities, the sign-incheck and the idle sign-in browser. A state that cannot be read or whose cookies the browser refuses throws as
state loaddid; storage that did not go back is named in the existing restore outcome.restoreStatus(from astate loadreply field v0.38.1 never sends) is gone with it.Checks: typecheck, lint (biome + discipline), pi lane. Local stack: signed-in Verifications on all three eval
products (passed, a fault run failed correctly) and two signed-in walks (completed); those products sign in with
cookies only, so a headless Chromium check covered the storages: cookies, localStorage (including quotes and line
breaks) and sessionStorage were all there when the page opened in the same tab, the product server saw no request
before that open, and the restore took 157 ms.
https://claude.ai/code/session_01QXmSJBFujofueuHrdm6TdA