[AP-2925] Enable server-side caching by default in v4 - #2964
sameelarif wants to merge 3 commits into
Conversation
v3 cached every eligible act/observe/extract unless the call opted out via `serverCache: false` — the server decided, gated on the per-project LaunchDarkly flag. v4 added a client-side gate that defaults to off, so `withCache` returns before it ever calls /v1/cache/get and metadata reports DISABLED. Anyone who upgraded without passing `cache` silently lost caching, including projects with the LaunchDarkly flag already enabled. Flip the default so v4 matches v3: caching is on unless the instance or the call opts out. The server still gates every lookup on `stagehand-api-server-caching`, so this only decides whether we ask. No existing test covered the default — baseArgs() always passed `caching: true` — which is how the inversion shipped. Added three: the buildCacheContext default, an explicit opt-out, and a lookup with neither the request nor the instance setting `cache`. Docs said caching was opt-in, which this makes wrong. Also corrects the v3 migration guide, which mapped `enableCaching` (a v2-era local option that v3 had already replaced with `cacheDir`) to `cache`, and never mentioned `serverCache` — the option v3 users actually had. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
|
There was a problem hiding this comment.
All reported issues were addressed across 4 files
Architecture diagram
sequenceDiagram
participant App as Client App
participant SH as Stagehand Client v4
participant CacheSvc as Cache Service
participant API as Stagehand API
participant LD as LaunchDarkly
participant Cache as Cache Store
Note over App, Cache: Caching Flow
App->>SH: create({ browser, apiKey })
SH->>CacheSvc: buildCacheContext(initParams)
CacheSvc->>CacheSvc: defaultCaching = cache ?? true
App->>SH: act("...") or observe() or extract()
SH->>CacheSvc: withCache({ caching, context, execute })
alt Request or instance sets cache: false
CacheSvc->>CacheSvc: resolvedCaching = false
CacheSvc->>SH: execute() directly
SH-->>App: Result with cache.status = "DISABLED"
else Default path (no explicit cache option)
CacheSvc->>CacheSvc: resolvedCaching = defaultCaching (true)
CacheSvc->>CacheSvc: cachePage = asCachePage(page)
CacheSvc->>API: GET /v1/cache/get
API->>LD: Check stagehand-api-server-caching flag
alt Flag disabled per project
LD-->>API: false
API-->>CacheSvc: No cache lookup
CacheSvc->>CacheSvc: execute()
SH-->>App: Result with cache.status = "DISABLED"
else Flag enabled per project
LD-->>API: true
API->>Cache: Lookup by cache key
alt Cache hit
Cache-->>API: Cached result
API-->>CacheSvc: Cache hit
CacheSvc->>CacheSvc: onHit()
SH-->>App: Result with cache.status = "HIT"
else Cache miss
Cache-->>API: Not found
API-->>CacheSvc: Miss
CacheSvc->>CacheSvc: execute()
API->>Cache: Store result
SH-->>App: Result with cache.status = "MISS"
end
end
end
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
- Locator-scoped calls bypass the cache entirely (shouldBypassCacheForLocatorScope gates act/observe/extract on `locator` or a non-empty `ignoreLocators`, and withCache returns before any read or write). The intro claimed every call is cached, contradicting the page's own note further down. Qualify it and add the exclusion to Limitations, which is where the other caching caveats live. - Drop the two em dashes, prohibited by .cubic/docs-style-guide.md:38. - `page.act` is not a v4 API and `page` was never declared in that snippet, so the opt-out example failed when copied. Use `stagehand.act`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
All reported issues were addressed across 2 files (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
docs-style-guide.md:35 mandates active voice, and the limitation bullet used
two passives ("are not cached", "is keyed") with no actor, which also made it
inconsistent with its neighbours ("Stagehand calls the LLM", "Stagehand falls
back"). Name Stagehand as the actor.
Two more of the same class in this PR's prose that review did not flag:
"Caching is enabled by default" is the guide's own example pattern, and
"request made by that instance" is a passive participle. Also corrects
"behaviour", the only British spelling against 13 uses of "behavior" in the
v4 docs.
Leaves the matching passive on line 346 alone: it is untouched legacy, and
the guide says not to block a focused PR on that.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
v4 shipped with server-side caching opt-in, where v3 had it on by default. Anyone who upgraded without passing
cachelost caching without an error.Change
Both defaults flip to
true, so v4 matches v3: caching runs unless the instance or the call opts out.Docs
v4/best-practices/caching.mdxdescribed opt-in, which this makes wrong.The v3 migration guide also mapped
enableCaching→cache.enableCachingwas a v2-era local option that v3 had already replaced withcacheDir; the server-side option v3 users actually had wasserverCache, which appeared nowhere in the v4 docs. Corrected the mapping and the diff example.🤖 Generated with Claude Code
Summary by cubic
Fixes AP-2925 by restoring v3’s caching default in v4: caching was opt-in and is now enabled unless the instance or call opts out. This prevents upgrades from silently losing caching; the server’s project feature flag still controls availability.
serverCachetocacheand remove outdatedenableCaching/cacheDirmappings.DISABLEDstatus, and thestagehand.actopt-out example.Written for commit 5bedb73. Summary will update on new commits.