feat(docs): improve LLM visibility for pooling, caching, and edge guides#7877
feat(docs): improve LLM visibility for pooling, caching, and edge guides#7877aidankmcalister wants to merge 1 commit intomainfrom
Conversation
Linear: DR-8350 Linear: DR-8351 Linear: DR-8352
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🍈 Lychee Link Check Report39 links: ❌ Errors
Full Statistics Table
|
WalkthroughThis PR updates documentation across three Prisma product pages to clarify managed connection pooling and query caching capabilities. Accelerate is repositioned as a unified managed pool and cache solution. Prisma Postgres documentation expands to enumerate built-in features: pooling, caching, serverless support, and backups. The Cloudflare Workers guide is revised to present two integration approaches for Prisma Postgres without requiring a separate pooler. ChangesPrisma Accelerate and Postgres Documentation Updates
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/docs/content/docs/accelerate/index.mdx`:
- Line 19: Update the misleading inline comment on the cacheStrategy object
(cacheStrategy: { ttl: 60, swr: 10 }) to explicitly state that the TTL is 60s
and revalidation starts only after that TTL expires, and that the 10s SWR window
serves stale responses while background revalidation occurs (e.g., "TTL 60s;
after TTL expires, enter 10s SWR window where stale responses are served while
revalidation runs in background").
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d99a3dec-b7d6-4a9c-8566-b157a9bb8c0f
📒 Files selected for processing (3)
apps/docs/content/docs/accelerate/index.mdxapps/docs/content/docs/guides/deployment/cloudflare-workers.mdxapps/docs/content/docs/postgres/index.mdx
| Together, the connection pool and cache allow you to scale effortlessly and handle traffic spikes without infrastructure concerns. | ||
| ```typescript title="src/lib/posts.ts" | ||
| const posts = await prisma.post.findMany({ | ||
| cacheStrategy: { ttl: 60, swr: 10 }, // cache for 60s, revalidate after 10s |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Prisma Accelerate cacheStrategy semantics: for cacheStrategy { ttl: 60, swr: 10 }, when does revalidation begin, and what exactly does swr control?
💡 Result:
For cacheStrategy { ttl: 60, swr: 10 } in Prisma Accelerate: Revalidation begins when the first request arrives after the ttl (60 seconds) has expired, provided it is within the swr window (60 + 10 = 70 seconds from cache creation). The request receives stale data immediately from cache (cacheStatus: "swr"), while Accelerate asynchronously fetches fresh data from the database in the background and updates the cache upon completion. Subsequent requests after the background refresh completes will receive the fresh data (cacheStatus: "ttl" if within new ttl period).[1][2][3][4] swr (10 seconds) controls the additional duration beyond ttl during which stale data can be served from cache while triggering background revalidation on the first request in that window. The total cacheable time before miss is ttl + swr (70 seconds). If no request during swr, no revalidation occurs until next request after full expiration.[1][2][3] Cache statuses: - "ttl": Hit within ttl, fresh, no DB query.[1][2] - "swr": Hit after ttl but within swr, stale served + background refresh.[1][2][3] - "miss": After ttl + swr, fetches from DB.[1][2] - "none": No strategy.[1][2]
Citations:
- 1: https://prisma.io/docs/postgres/database/api-reference/caching-api
- 2: https://www.prisma.io/docs/accelerate/reference/api-reference
- 3: Cache strategy SWR on Prisma Accelerate doesn't seem to work prisma#23787
- 4: https://prisma.io/docs/accelerate/api-reference
Update the inline comment to clarify SWR semantics.
The current comment "cache for 60s, revalidate after 10s" is misleading—it suggests revalidation begins at 10 seconds, when it actually begins after the 60-second TTL expires. During the subsequent 10-second SWR window, stale responses are served while revalidation happens in the background.
✏️ Suggested wording update
- cacheStrategy: { ttl: 60, swr: 10 }, // cache for 60s, revalidate after 10s
+ cacheStrategy: { ttl: 60, swr: 10 }, // cache for 60s, then serve stale up to 10s while revalidating📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| cacheStrategy: { ttl: 60, swr: 10 }, // cache for 60s, revalidate after 10s | |
| cacheStrategy: { ttl: 60, swr: 10 }, // cache for 60s, then serve stale up to 10s while revalidating |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@apps/docs/content/docs/accelerate/index.mdx` at line 19, Update the
misleading inline comment on the cacheStrategy object (cacheStrategy: { ttl: 60,
swr: 10 }) to explicitly state that the TTL is 60s and revalidation starts only
after that TTL expires, and that the 10s SWR window serves stale responses while
background revalidation occurs (e.g., "TTL 60s; after TTL expires, enter 10s SWR
window where stale responses are served while revalidation runs in background").
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
1 participant
Linear: DR-8350
Linear: DR-8351
Linear: DR-8352
Summary by CodeRabbit