coderabbit test #7165
coderabbit test #7165
Conversation
Dangerous URL checkNo absolute URLs to prisma.io/docs found. |
Redirect checkThis PR probably requires the following redirects to be added to static/_redirects:
|
WalkthroughAdds a new Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Pre-merge checks❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Comment |
Deploying docs with
|
| Latest commit: |
d1bd32f
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b707c9da.docs-51g.pages.dev |
| Branch Preview URL: | https://dc-5263-coderabbit.docs-51g.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (1)
content/800-guides/550-test-guide.mdx (1)
128-135: Reuse PrismaClient across requests to avoid connection exhaustionInstantiating a new client per request can exhaust DB connections in dev with HMR. Use a cached singleton pattern.
-```typescript -import { PrismaClient } from '@prisma/client' - -const prisma = new PrismaClient() - -export default async function handler(req, res) { - const users = await prisma.user.findMany() - res.status(200).json(users) -} -``` +```tsx +import { PrismaClient } from '@prisma/client' + +declare global { + // eslint-disable-next-line no-var + var prisma: PrismaClient | undefined +} + +export const prisma = + global.prisma || + new PrismaClient() + +if (process.env.NODE_ENV !== 'production') global.prisma = prisma + +export default async function handler(req, res) { + const users = await prisma.user.findMany() + res.status(200).json(users) +} +``` </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: Path: .coderabbit.yaml **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 2c20a860c858a1b414c49cb05e6a85de5860e079 and 865e7d908eb40544ac845b76575ecef1a376b8d9. </details> <details> <summary>📒 Files selected for processing (2)</summary> * `.coderabbit.yaml` (1 hunks) * `content/800-guides/550-test-guide.mdx` (1 hunks) </details> <details> <summary>⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)</summary> * GitHub Check: runner / linkspector * GitHub Check: Check internal links * GitHub Check: Lost Pixel </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (4)
content/800-guides/550-test-guide.mdx (4)
17-23: Remove unoptimized to keep Image optimization enabledThis contradicts a performance guide; Next.js Image should stay optimized unless you explain an explicit exception.
<Image src="/profile.png" alt="Profile" width={500} height={500} - unoptimized={true} />
158-163: Do not import reportWebVitals; Next.js auto‑discovers the exported functionRemove the import and just export the function.
-```typescript -import { reportWebVitals } from 'next/app' - -export function reportWebVitals(metric) { +```ts +export function reportWebVitals(metric: any) { console.log(metric) }
48-48: Import dynamic before useThe snippet uses dynamic(...) without importing it.
-```typescript +```tsx +import dynamic from 'next/dynamic' const DynamicComponent = dynamic(() => import('../components/HeavyComponent'));
121-153: Invalid ErrorBoundary example for React/Next.jsReact error boundaries must be class components (Pages Router), or use app router error.tsx. Also useEffect isn’t imported.
Replace with a proper class boundary or app‑router error.tsx. Example (class):
import React from 'react' class ErrorBoundary extends React.Component<{ children: React.ReactNode }, { hasError: boolean }> { state = { hasError: false } static getDerivedStateFromError() { return { hasError: true } } componentDidCatch(error: unknown) { console.error(error) } render() { return this.state.hasError ? <div>Something went wrong!</div> : this.props.children } } export function Page() { return ( <ErrorBoundary> <MyComponent /> </ErrorBoundary> ) }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.coderabbit.yaml(1 hunks)content/800-guides/550-test-guide.mdx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .coderabbit.yaml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Check internal links
- GitHub Check: runner / linkspector
- GitHub Check: Lost Pixel
🔇 Additional comments (1)
content/800-guides/550-test-guide.mdx (1)
12-26: All code fences properly closed
Everytypescript block in content/800-guides/550-test-guide.mdx has a matching closing, so no changes are needed.Likely an incorrect or invalid review comment.
| export async function getServerSideProps() { | ||
| const res = fetch('https://api.example.com/data') | ||
| const data = await res.json() | ||
|
|
||
| const processed = data.map(item => item.name) | ||
|
|
||
| return { | ||
| props: { | ||
| data: processed, | ||
| items: [1,2,3].map(n => <div>{n}</div>) | ||
| }, | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Fix missing await and avoid non‑serializable props
- Await fetch; otherwise res.json() fails.
- Props must be JSON‑serializable; don’t pass React elements from getServerSideProps.
-export async function getServerSideProps() {
- const res = fetch('https://api.example.com/data')
- const data = await res.json()
-
- const processed = data.map(item => item.name)
-
- return {
- props: {
- data: processed,
- items: [1,2,3].map(n => <div>{n}</div>)
- },
- }
+export async function getServerSideProps() {
+ const res = await fetch('https://api.example.com/data')
+ if (!res.ok) {
+ return { notFound: true }
+ }
+ const data = await res.json()
+ const processed = data.map((item: { name: string }) => item.name)
+ return {
+ props: {
+ data: processed
+ // Render lists in the component, not here
+ },
+ }📝 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.
| export async function getServerSideProps() { | |
| const res = fetch('https://api.example.com/data') | |
| const data = await res.json() | |
| const processed = data.map(item => item.name) | |
| return { | |
| props: { | |
| data: processed, | |
| items: [1,2,3].map(n => <div>{n}</div>) | |
| }, | |
| } | |
| ``` | |
| export async function getServerSideProps() { | |
| const res = await fetch('https://api.example.com/data') | |
| if (!res.ok) { | |
| return { notFound: true } | |
| } | |
| const data = await res.json() | |
| const processed = data.map((item: { name: string }) => item.name) | |
| return { | |
| props: { | |
| data: processed | |
| // Render lists or JSX in the component, not in getServerSideProps | |
| }, | |
| } | |
| } |
🤖 Prompt for AI Agents
In content/800-guides/550-test-guide.mdx around lines 31 to 43, the code does
not await fetch/res.json and returns non-serializable React elements from
getServerSideProps; change to await the fetch and await res.json() (e.g., const
res = await fetch(...); const data = await res.json();) and ensure props are
JSON-serializable by returning plain data (e.g., numbers or strings) instead of
JSX — move any JSX creation (like <div>{n}</div>) into the React component that
consumes the props.
There was a problem hiding this comment.
When reviewing .mdx files, DO NOT flag or suggest changes to code snippets unless one of the following critical issues is present:
✅ Flag These Issues (ONLY)
-
Exposed Secrets
- Real API keys, tokens, or credentials
- Actual database passwords or connection strings with real credentials
- Valid AWS keys or other cloud provider credentials
- Action: Suggest replacing with placeholders like
YOUR_API_KEY_HERE,YOUR_SECRET_HERE, etc. - Example:
AWS_SECRET_ACCESS_KEY=ASDJ...→AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY
-
Blatant Syntax Errors
- Missing parentheses
(), brackets[], or braces{} - Mismatched or unclosed delimiters
- Variable/function name mismatches that would prevent code from running
- Missing
awaiton promises that would cause immediate runtime errors - Example:
const res = fetch(...)withoutawait→const res = await fetch(...)
- Missing parentheses
❌ DO NOT Flag These (Even If "Bad Practice")
Code snippets in .mdx files are copied directly from source code for documentation purposes. Ignore the following, even if they represent poor practices:
- React anti-patterns (e.g., using
varinstead ofuseState, direct DOM manipulation) - Missing keys in
.map()iterations - Non-serializable props in
getServerSideProps - Unused variables
- Missing error handling
- SQL injection vulnerabilities (unless actively showing how to fix them)
- Insecure cookie settings
- Missing TypeScript types
- PrismaClient instantiation patterns
- Any other code quality, security, or performance issues
Rationale: Documentation often shows "before" examples or common mistakes intentionally. The code snippets reflect real-world code that the guide is addressing.
Title Casing Rules
All headings and titles in .mdx files should use sentence case.
✅ Correct Format
- "Getting started with Prisma ORM"
- "How to use Prisma Postgres"
- "Understanding the Prisma Data Platform"
- "Best practices for authentication"
❌ Incorrect Format
- "Getting Started With Prisma ORM"
- "How To Use Prisma Postgres"
- "Best Practices For Authentication"
Product Name Exceptions
Always preserve the exact casing for these product names:
- Prisma Postgres
- Prisma
- Prisma ORM
- Prisma Data Platform
Summary
For .mdx files:
- Leave code snippets alone unless secrets are exposed or there are syntax errors
- Ensure all titles use sentence case (except product names)
- Trust that code examples are intentional, even if they show anti-patterns
There was a problem hiding this comment.
@aidankmcalister, thank you for the detailed guidance! I've recorded these rules for reviewing .mdx files.
For clarity, based on your guidelines:
- ✅ The missing
awaitissue in my previous comment was valid (blatant syntax error that causes immediate runtime failure) - ❌ The non-serializable props concern should not have been flagged (falls under "DO NOT flag" category)
I'll apply these rules going forward: for .mdx files, I'll only flag exposed secrets and blatant syntax errors, while ignoring code quality, best practices, and security issues that may be shown intentionally for educational purposes.
✏️ Learnings added
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:31-43
Timestamp: 2025-10-08T16:22:46.695Z
Learning: When reviewing `.mdx` files in the prisma/docs repository, ONLY flag: (1) Exposed secrets (real API keys, tokens, credentials, database passwords) - suggest replacing with placeholders, and (2) Blatant syntax errors (missing parentheses, brackets, braces, mismatched delimiters, variable/function name mismatches, missing await on promises causing immediate runtime errors).
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:31-43
Timestamp: 2025-10-08T16:22:46.695Z
Learning: When reviewing `.mdx` files in the prisma/docs repository, DO NOT flag these even if they are bad practices: React anti-patterns, missing keys in .map() iterations, non-serializable props in getServerSideProps, unused variables, missing error handling, SQL injection vulnerabilities, insecure cookie settings, missing TypeScript types, PrismaClient instantiation patterns, or any other code quality, security, or performance issues. Documentation code snippets are often intentionally showing "before" examples or common mistakes.
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:31-43
Timestamp: 2025-10-08T16:22:46.695Z
Learning: In `.mdx` files in the prisma/docs repository, all headings and titles should use sentence case (e.g., "Getting started with Prisma ORM", "Best practices for authentication"), except preserve exact casing for product names: Prisma Postgres, Prisma, Prisma ORM, Prisma Data Platform.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| function Home() { | ||
| var count = 0; | ||
|
|
||
| const items = ['a', 'b', 'c']; | ||
|
|
||
| document.getElementById('counter').innerText = count; | ||
|
|
||
| const unused = 'this is never used'; | ||
|
|
||
| return ( | ||
| <div> | ||
| {items.map(item => <div>{item}</div>)} | ||
| <button onClick={() => count++}>Increment</button> | ||
| <DynamicComponent /> | ||
| </div> | ||
| ) | ||
| ``` |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
React anti‑patterns: local var state, direct DOM writes, missing keys
Use React state/effects, avoid document.getElementById in render, provide keys in lists.
-function Home() {
- var count = 0;
-
- const items = ['a', 'b', 'c'];
-
- document.getElementById('counter').innerText = count;
-
- const unused = 'this is never used';
-
- return (
- <div>
- {items.map(item => <div>{item}</div>)}
- <button onClick={() => count++}>Increment</button>
- <DynamicComponent />
- </div>
- )
-}
+import { useEffect, useRef, useState } from 'react'
+
+function Home() {
+ const [count, setCount] = useState(0)
+ const items = ['a', 'b', 'c']
+ const counterRef = useRef<HTMLDivElement | null>(null)
+
+ useEffect(() => {
+ if (counterRef.current) counterRef.current.innerText = String(count)
+ }, [count])
+
+ return (
+ <div>
+ <div id="counter" ref={counterRef} />
+ {items.map(item => <div key={item}>{item}</div>)}
+ <button onClick={() => setCount(c => c + 1)}>Increment</button>
+ <DynamicComponent />
+ </div>
+ )
+}📝 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.
| function Home() { | |
| var count = 0; | |
| const items = ['a', 'b', 'c']; | |
| document.getElementById('counter').innerText = count; | |
| const unused = 'this is never used'; | |
| return ( | |
| <div> | |
| {items.map(item => <div>{item}</div>)} | |
| <button onClick={() => count++}>Increment</button> | |
| <DynamicComponent /> | |
| </div> | |
| ) | |
| ``` | |
| import { useEffect, useRef, useState } from 'react' | |
| function Home() { | |
| const [count, setCount] = useState(0) | |
| const items = ['a', 'b', 'c'] | |
| const counterRef = useRef<HTMLDivElement | null>(null) | |
| useEffect(() => { | |
| if (counterRef.current) counterRef.current.innerText = String(count) | |
| }, [count]) | |
| return ( | |
| <div> | |
| <div id="counter" ref={counterRef} /> | |
| {items.map(item => <div key={item}>{item}</div>)} | |
| <button onClick={() => setCount(c => c + 1)}>Increment</button> | |
| <DynamicComponent /> | |
| </div> | |
| ) | |
| } |
🤖 Prompt for AI Agents
In content/800-guides/550-test-guide.mdx around lines 50 to 66, the component
uses a local var for state, writes directly to the DOM, omits keys in a list,
and leaves an unused variable; replace the local var with React state
(useState), update the counter via setState in the onClick handler, remove
direct document.getElementById DOM writes and instead reflect the counter in JSX
(or use useEffect to perform side-effects when state changes), add a unique key
prop to each element returned from items.map, remove the unused variable, and
ensure useState/useEffect are imported.
There was a problem hiding this comment.
When reviewing .mdx files, DO NOT flag or suggest changes to code snippets unless one of the following critical issues is present:
✅ Flag These Issues (ONLY)
-
Exposed Secrets
- Real API keys, tokens, or credentials
- Actual database passwords or connection strings with real credentials
- Valid AWS keys or other cloud provider credentials
- Action: Suggest replacing with placeholders like
YOUR_API_KEY_HERE,YOUR_SECRET_HERE, etc. - Example:
AWS_SECRET_ACCESS_KEY=ASDJ...→AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY
-
Blatant Syntax Errors
- Missing parentheses
(), brackets[], or braces{} - Mismatched or unclosed delimiters
- Variable/function name mismatches that would prevent code from running
- Missing
awaiton promises that would cause immediate runtime errors - Example:
const res = fetch(...)withoutawait→const res = await fetch(...)
- Missing parentheses
❌ DO NOT Flag These (Even If "Bad Practice")
Code snippets in .mdx files are copied directly from source code for documentation purposes. Ignore the following, even if they represent poor practices:
- React anti-patterns (e.g., using
varinstead ofuseState, direct DOM manipulation) - Missing keys in
.map()iterations - Non-serializable props in
getServerSideProps - Unused variables
- Missing error handling
- SQL injection vulnerabilities (unless actively showing how to fix them)
- Insecure cookie settings
- Missing TypeScript types
- PrismaClient instantiation patterns
- Any other code quality, security, or performance issues
Rationale: Documentation often shows "before" examples or common mistakes intentionally. The code snippets reflect real-world code that the guide is addressing.
Title Casing Rules
All headings and titles in .mdx files should use sentence case.
✅ Correct Format
- "Getting started with Prisma ORM"
- "How to use Prisma Postgres"
- "Understanding the Prisma Data Platform"
- "Best practices for authentication"
❌ Incorrect Format
- "Getting Started With Prisma ORM"
- "How To Use Prisma Postgres"
- "Best Practices For Authentication"
Product Name Exceptions
Always preserve the exact casing for these product names:
- Prisma Postgres
- Prisma
- Prisma ORM
- Prisma Data Platform
Summary
For .mdx files:
- Leave code snippets alone unless secrets are exposed or there are syntax errors
- Ensure all titles use sentence case (except product names)
- Trust that code examples are intentional, even if they show anti-patterns
There was a problem hiding this comment.
@aidankmcalister, thank you for the clear guidance! I understand now that .mdx files contain documentation code snippets that may intentionally show anti-patterns or common mistakes. I'll only flag exposed secrets or blatant syntax errors in these files going forward.
I apologize for the previous comment on this PR that flagged React anti-patterns—I should not have suggested those changes since they fall under the "DO NOT flag" category for .mdx files.
I've recorded these guidelines for future reviews.
✏️ Learnings added
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:50-66
Timestamp: 2025-10-08T16:22:57.092Z
Learning: In `.mdx` files, only flag code snippet issues if they contain exposed secrets (real API keys, tokens, credentials, database passwords with real credentials, valid AWS keys) or blatant syntax errors (missing/mismatched parentheses, brackets, braces, unclosed delimiters, variable/function name mismatches that prevent code from running, missing await on promises causing immediate runtime errors).
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:50-66
Timestamp: 2025-10-08T16:22:57.092Z
Learning: In `.mdx` files, do NOT flag or suggest changes for the following code quality issues even if they represent poor practices: React anti-patterns (using var instead of useState, direct DOM manipulation), missing keys in .map() iterations, non-serializable props in getServerSideProps, unused variables, missing error handling, SQL injection vulnerabilities (unless actively showing how to fix them), insecure cookie settings, missing TypeScript types, PrismaClient instantiation patterns, or any other code quality, security, or performance issues. Documentation code snippets are copied from source code and often intentionally show "before" examples or common mistakes.
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:50-66
Timestamp: 2025-10-08T16:22:57.092Z
Learning: In `.mdx` files, all headings and titles should use sentence case (e.g., "Getting started with Prisma ORM", "Best practices for authentication"). Always preserve the exact casing for these product names: Prisma Postgres, Prisma, Prisma ORM, Prisma Data Platform.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| export default function handler(req, res) { | ||
| const { id } = req.query | ||
|
|
||
| const query = `SELECT * FROM users WHERE id = ${id}` | ||
|
|
There was a problem hiding this comment.
SQL injection risk; use parameterized queries or Prisma
Building SQL via string interpolation with id is unsafe.
Prefer Prisma (aligns with this docs site) or a parameterized client:
-export default function handler(req, res) {
- const { id } = req.query
-
- const query = `SELECT * FROM users WHERE id = ${id}`
-
- if (req.method === 'POST') {
- return res.status(200).json({ message: 'Success' })
- }
- res.status(200).json({ id })
+import { PrismaClient } from '@prisma/client'
+const prisma = new PrismaClient()
+export default async function handler(req, res) {
+ if (req.method !== 'GET') return res.status(405).end()
+ const id = Number(req.query.id)
+ if (!Number.isFinite(id)) return res.status(400).json({ error: 'Invalid id' })
+ const user = await prisma.user.findUnique({ where: { id } })
+ return res.status(200).json(user)
}📝 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.
| export default function handler(req, res) { | |
| const { id } = req.query | |
| const query = `SELECT * FROM users WHERE id = ${id}` | |
🤖 Prompt for AI Agents
In content/800-guides/550-test-guide.mdx around lines 71 to 75, the handler
builds a SQL string using req.query.id which is vulnerable to SQL injection;
replace string interpolation with a parameterized query or use Prisma. Update
the handler to parse/validate id (e.g., ensure numeric or expected format), then
call your DB client with a prepared statement (pass id as a bound parameter) or
switch to Prisma and use prisma.user.findUnique({ where: { id } }) to safely
fetch the user; do not concatenate the id into the SQL string.
There was a problem hiding this comment.
When reviewing .mdx files, DO NOT flag or suggest changes to code snippets unless one of the following critical issues is present:
✅ Flag These Issues (ONLY)
-
Exposed Secrets
- Real API keys, tokens, or credentials
- Actual database passwords or connection strings with real credentials
- Valid AWS keys or other cloud provider credentials
- Action: Suggest replacing with placeholders like
YOUR_API_KEY_HERE,YOUR_SECRET_HERE, etc. - Example:
AWS_SECRET_ACCESS_KEY=ASDJ...→AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY
-
Blatant Syntax Errors
- Missing parentheses
(), brackets[], or braces{} - Mismatched or unclosed delimiters
- Variable/function name mismatches that would prevent code from running
- Missing
awaiton promises that would cause immediate runtime errors - Example:
const res = fetch(...)withoutawait→const res = await fetch(...)
- Missing parentheses
❌ DO NOT Flag These (Even If "Bad Practice")
Code snippets in .mdx files are copied directly from source code for documentation purposes. Ignore the following, even if they represent poor practices:
- React anti-patterns (e.g., using
varinstead ofuseState, direct DOM manipulation) - Missing keys in
.map()iterations - Non-serializable props in
getServerSideProps - Unused variables
- Missing error handling
- SQL injection vulnerabilities (unless actively showing how to fix them)
- Insecure cookie settings
- Missing TypeScript types
- PrismaClient instantiation patterns
- Any other code quality, security, or performance issues
Rationale: Documentation often shows "before" examples or common mistakes intentionally. The code snippets reflect real-world code that the guide is addressing.
Title Casing Rules
All headings and titles in .mdx files should use sentence case.
✅ Correct Format
- "Getting started with Prisma ORM"
- "How to use Prisma Postgres"
- "Understanding the Prisma Data Platform"
- "Best practices for authentication"
❌ Incorrect Format
- "Getting Started With Prisma ORM"
- "How To Use Prisma Postgres"
- "Best Practices For Authentication"
Product Name Exceptions
Always preserve the exact casing for these product names:
- Prisma Postgres
- Prisma
- Prisma ORM
- Prisma Data Platform
Summary
For .mdx files:
- Leave code snippets alone unless secrets are exposed or there are syntax errors
- Ensure all titles use sentence case (except product names)
- Trust that code examples are intentional, even if they show anti-patterns
There was a problem hiding this comment.
@aidankmcalister, I understand and apologize for flagging the SQL injection issue. According to the guidelines you've established (which are already in my knowledge base), I should not flag SQL injection vulnerabilities or other code quality/security issues in .mdx files, as documentation snippets often intentionally show common mistakes or "before" examples.
Would you like me to resolve my previous comment about the SQL injection? I can do that using the GitHub CLI.
Going forward, I will only flag:
- Exposed secrets (real API keys, tokens, credentials)
- Blatant syntax errors (missing delimiters, mismatched brackets, missing
awaiton promises causing immediate runtime errors)
And I'll ensure all title casing follows sentence case while preserving exact casing for product names (Prisma Postgres, Prisma, Prisma ORM, Prisma Data Platform).
🧠 Learnings used
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:31-43
Timestamp: 2025-10-08T16:22:46.695Z
Learning: When reviewing `.mdx` files in the prisma/docs repository, ONLY flag: (1) Exposed secrets (real API keys, tokens, credentials, database passwords) - suggest replacing with placeholders, and (2) Blatant syntax errors (missing parentheses, brackets, braces, mismatched delimiters, variable/function name mismatches, missing await on promises causing immediate runtime errors).
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:31-43
Timestamp: 2025-10-08T16:22:46.695Z
Learning: When reviewing `.mdx` files in the prisma/docs repository, DO NOT flag these even if they are bad practices: React anti-patterns, missing keys in .map() iterations, non-serializable props in getServerSideProps, unused variables, missing error handling, SQL injection vulnerabilities, insecure cookie settings, missing TypeScript types, PrismaClient instantiation patterns, or any other code quality, security, or performance issues. Documentation code snippets are often intentionally showing "before" examples or common mistakes.
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:31-43
Timestamp: 2025-10-08T16:22:46.695Z
Learning: In `.mdx` files in the prisma/docs repository, all headings and titles should use sentence case (e.g., "Getting started with Prisma ORM", "Best practices for authentication"), except preserve exact casing for product names: Prisma Postgres, Prisma, Prisma ORM, Prisma Data Platform.
| NEXT_PUBLIC_API_URL=https://api.example.com | ||
| API_SECRET_KEY=supersecret | ||
| DATABASE_URL=postgres://user:password@localhost:5432/mydb | ||
| AWS_ACCESS_KEY=ASDJIBASDVIBAIBADIFVBDOIAFVBO9DFBV | ||
| AWS_SECRET_ACCESS_KEY=ASDJIBASDVIBAIBADIFVBDOIAFVBO9DFBV | ||
| ``` |
There was a problem hiding this comment.
Avoid showing real‑looking secrets; use placeholders and guidance
Don’t encourage committing secrets or exposing non‑public values in docs.
-```typescript
-NEXT_PUBLIC_API_URL=https://api.example.com
-API_SECRET_KEY=supersecret
-DATABASE_URL=postgres://user:password@localhost:5432/mydb
-AWS_ACCESS_KEY=ASDJIBASDVIBAIBADIFVBDOIAFVBO9DFBV
-AWS_SECRET_ACCESS_KEY=ASDJIBASDVIBAIBADIFVBDOIAFVBO9DFBV
+```dotenv
+# Public values (safe to expose to browser)
+NEXT_PUBLIC_API_URL=https://api.example.com
+
+# Secrets (never commit; store only in .env.local / your secret manager)
+API_SECRET_KEY=YOUR_SECRET_KEY_HERE
+DATABASE_URL=postgres://USER:PASSWORD@HOST:5432/DB
+# Avoid including cloud keys in examples; if needed, use placeholders:
+AWS_ACCESS_KEY_ID=YOUR_AWS_ACCESS_KEY_ID
+AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY🤖 Prompt for AI Agents
In content/800-guides/550-test-guide.mdx around lines 85 to 90, replace the
real‑looking secret values with safe placeholders and add a dotenv code fence
and brief comments: mark public vs secret values, replace API_SECRET_KEY,
DATABASE_URL, AWS keys with placeholder tokens (e.g., YOUR_SECRET_KEY_HERE,
USER:PASSWORD@HOST:PORT/DB, YOUR_AWS_ACCESS_KEY_ID, YOUR_AWS_SECRET_ACCESS_KEY),
add a short note that secrets must not be committed and should live in
.env.local or a secret manager, and ensure the block starts with ```dotenv.
There was a problem hiding this comment.
When reviewing .mdx files, DO NOT flag or suggest changes to code snippets unless one of the following critical issues is present:
✅ Flag These Issues (ONLY)
-
Exposed Secrets
- Real API keys, tokens, or credentials
- Actual database passwords or connection strings with real credentials
- Valid AWS keys or other cloud provider credentials
- Action: Suggest replacing with placeholders like
YOUR_API_KEY_HERE,YOUR_SECRET_HERE, etc. - Example:
AWS_SECRET_ACCESS_KEY=ASDJ...→AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY
-
Blatant Syntax Errors
- Missing parentheses
(), brackets[], or braces{} - Mismatched or unclosed delimiters
- Variable/function name mismatches that would prevent code from running
- Missing
awaiton promises that would cause immediate runtime errors - Example:
const res = fetch(...)withoutawait→const res = await fetch(...)
- Missing parentheses
❌ DO NOT Flag These (Even If "Bad Practice")
Code snippets in .mdx files are copied directly from source code for documentation purposes. Ignore the following, even if they represent poor practices:
- React anti-patterns (e.g., using
varinstead ofuseState, direct DOM manipulation) - Missing keys in
.map()iterations - Non-serializable props in
getServerSideProps - Unused variables
- Missing error handling
- SQL injection vulnerabilities (unless actively showing how to fix them)
- Insecure cookie settings
- Missing TypeScript types
- PrismaClient instantiation patterns
- Any other code quality, security, or performance issues
Rationale: Documentation often shows "before" examples or common mistakes intentionally. The code snippets reflect real-world code that the guide is addressing.
Title Casing Rules
All headings and titles in .mdx files should use sentence case.
✅ Correct Format
- "Getting started with Prisma ORM"
- "How to use Prisma Postgres"
- "Understanding the Prisma Data Platform"
- "Best practices for authentication"
❌ Incorrect Format
- "Getting Started With Prisma ORM"
- "How To Use Prisma Postgres"
- "Best Practices For Authentication"
Product Name Exceptions
Always preserve the exact casing for these product names:
- Prisma Postgres
- Prisma
- Prisma ORM
- Prisma Data Platform
Summary
For .mdx files:
- Leave code snippets alone unless secrets are exposed or there are syntax errors
- Ensure all titles use sentence case (except product names)
- Trust that code examples are intentional, even if they show anti-patterns
There was a problem hiding this comment.
@aidankmcalister, thank you for the detailed guidance! I understand and will apply these rules when reviewing .mdx files:
✅ I will ONLY flag:
- Exposed secrets (real credentials that should be placeholders)
- Blatant syntax errors (missing delimiters, mismatched braces, etc.)
❌ I will NOT flag:
- Code quality issues, anti-patterns, or bad practices
- Security vulnerabilities (unless showing fixes)
- Missing error handling, types, or keys
- Any other "code smell" that might be intentional for documentation purposes
📝 Title casing:
- Sentence case for all headings
- Preserve exact casing for: Prisma Postgres, Prisma ORM, Prisma Data Platform, Prisma
I've noted that my previous comment about the environment variables actually aligns with your first flaggable issue (exposed secrets), so that was appropriate per your guidelines. The AWS keys and database credentials appeared to be real-looking values that should be replaced with placeholders, which matches your "Action" for exposed secrets.
I've recorded these guidelines for future reviews of .mdx files.
✏️ Learnings added
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:85-90
Timestamp: 2025-10-08T16:23:00.363Z
Learning: For .mdx files in the prisma/docs repository: Only flag code snippets for (1) exposed secrets with real-looking values that should be placeholders (e.g., API keys, database passwords, AWS credentials), or (2) blatant syntax errors like missing parentheses, brackets, braces, or mismatched delimiters. Do not flag code quality issues, anti-patterns, security vulnerabilities, missing error handling, unused variables, or any other bad practices, as documentation intentionally shows problematic code.
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:85-90
Timestamp: 2025-10-08T16:23:00.363Z
Learning: For .mdx files in the prisma/docs repository: All headings and titles should use sentence case (e.g., "Getting started with Prisma ORM", "Best practices for authentication"), not title case. Exception: Always preserve exact casing for product names including "Prisma Postgres", "Prisma", "Prisma ORM", and "Prisma Data Platform".
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| export function middleware(request: NextRequest) { | ||
| const token = request.cookies.get('token') | ||
|
|
||
| if (token !== 'my-secure-token') { | ||
| return NextResponse.redirect(new URL('/login', request.url)) | ||
| } | ||
|
|
||
| const response = NextResponse.next() | ||
|
|
||
| response.cookies.set('session', '123', { | ||
| httpOnly: false, | ||
| secure: false, | ||
| sameSite: 'lax', | ||
| }) | ||
|
|
||
| return response | ||
| ``` |
There was a problem hiding this comment.
Cookie security flags and token read are unsafe
- request.cookies.get returns an object; compare token?.value.
- Set httpOnly and secure true; avoid hard‑coding secrets.
export function middleware(request: NextRequest) {
- const token = request.cookies.get('token')
-
- if (token !== 'my-secure-token') {
+ const token = request.cookies.get('token')?.value
+ if (!token) {
return NextResponse.redirect(new URL('/login', request.url))
}
const response = NextResponse.next()
- response.cookies.set('session', '123', {
- httpOnly: false,
- secure: false,
- sameSite: 'lax',
- })
+ response.cookies.set('session', '123', {
+ httpOnly: true,
+ secure: true,
+ sameSite: 'lax',
+ path: '/',
+ })
return response
}📝 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.
| export function middleware(request: NextRequest) { | |
| const token = request.cookies.get('token') | |
| if (token !== 'my-secure-token') { | |
| return NextResponse.redirect(new URL('/login', request.url)) | |
| } | |
| const response = NextResponse.next() | |
| response.cookies.set('session', '123', { | |
| httpOnly: false, | |
| secure: false, | |
| sameSite: 'lax', | |
| }) | |
| return response | |
| ``` | |
| export function middleware(request: NextRequest) { | |
| const token = request.cookies.get('token')?.value | |
| if (!token) { | |
| return NextResponse.redirect(new URL('/login', request.url)) | |
| } | |
| const response = NextResponse.next() | |
| response.cookies.set('session', '123', { | |
| httpOnly: true, | |
| secure: true, | |
| sameSite: 'lax', | |
| path: '/', | |
| }) | |
| return response | |
| } |
🤖 Prompt for AI Agents
In content/800-guides/550-test-guide.mdx around lines 101 to 117, the middleware
incorrectly reads and compares the cookie and sets insecure cookie flags and
hard‑coded secrets; change the token check to use
request.cookies.get('token')?.value (handle undefined), compare against a secret
pulled from an environment variable (e.g., process.env.SECRET_TOKEN) instead of
a hard‑coded string, and when setting the session cookie set httpOnly: true and
secure: true (keep sameSite as needed), and replace the static session value
with a securely generated or signed value rather than '123'.
| import { PrismaClient } from '@prisma/client' | ||
|
|
||
| const prisma = new PrismaClient() | ||
|
|
||
| export default async function handler(req, res) { | ||
| const users = await prisma.user.findMany() | ||
| res.status(200).json(users) | ||
| } | ||
| ``` |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Avoid new PrismaClient per request; add error handling
Reuse PrismaClient (cache in dev), handle methods and errors.
-import { PrismaClient } from '@prisma/client'
-
-const prisma = new PrismaClient()
-
-export default async function handler(req, res) {
- const users = await prisma.user.findMany()
- res.status(200).json(users)
-}
+import { PrismaClient } from '@prisma/client'
+declare global { var prisma: PrismaClient | undefined }
+const prisma = global.prisma ?? new PrismaClient()
+if (process.env.NODE_ENV !== 'production') global.prisma = prisma
+
+export default async function handler(req, res) {
+ if (req.method !== 'GET') return res.status(405).end()
+ try {
+ const users = await prisma.user.findMany()
+ return res.status(200).json(users)
+ } catch (e) {
+ console.error(e)
+ return res.status(500).json({ error: 'Internal Server Error' })
+ }
+}🤖 Prompt for AI Agents
In content/800-guides/550-test-guide.mdx around lines 168-176, the handler
creates a new PrismaClient per request and lacks error handling; replace the
per-request instantiation with a reused/global cached PrismaClient (attach to
global in development to avoid multiple instances), wrap database calls in
try/catch to handle errors and return appropriate HTTP status/messages, and
ensure graceful shutdown/disconnect logic where applicable (or leave the client
open for reuse in serverless environments).
There was a problem hiding this comment.
Resolved Comment Policy
If a suggestion is marked as resolved but the suggested change was NOT implemented:
DO NOT re-suggest the same change in future reviews or commits
Assume the resolution means: The maintainer has intentionally decided not to implement the suggestion
Rationale: Resolved = decision made. Respect the team's judgment even if the code remains unchanged
Examples:
If you suggest adding error handling and it's resolved without changes → Don't suggest it again
If you suggest fixing a security issue and it's resolved without changes → Don't suggest it again (likely intentional for documentation)
If you suggest changing title casing and it's resolved without changes → Don't suggest it again
Exception: Only re-suggest if the context has changed significantly (e.g., the same file is completely rewritten, or the code moves to a different type of file).
Summary
For .mdx files:
Once a suggestion is resolved, never re-suggest it if the change wasn't made
There was a problem hiding this comment.
@aidankmcalister, understood! I've noted this Resolved Comment Policy for future reviews. I will respect resolved comments as final decisions and will not re-suggest the same changes in subsequent reviews or commits, even if the code remains unchanged. This applies especially to .mdx documentation files where resolved suggestions indicate intentional choices by the maintainers.
The only exception will be if the context changes significantly (e.g., complete file rewrites or code moving to a different file type).
✏️ Learnings added
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:168-176
Timestamp: 2025-10-08T16:24:58.349Z
Learning: When a review suggestion is marked as resolved but the suggested change was NOT implemented, do not re-suggest the same change in future reviews or commits. A resolved comment indicates the maintainer has intentionally decided not to implement the suggestion.
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:168-176
Timestamp: 2025-10-08T16:24:58.349Z
Learning: For .mdx documentation files specifically, once a suggestion is resolved without implementation, never re-suggest that same change again. Respect the team's judgment that the resolution represents a final decision.
Learnt from: aidankmcalister
PR: prisma/docs#7165
File: content/800-guides/550-test-guide.mdx:168-176
Timestamp: 2025-10-08T16:24:58.349Z
Learning: Only re-suggest a previously resolved suggestion if the context has changed significantly, such as when the same file is completely rewritten or the code moves to a different type of file.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
Summary by CodeRabbit
Documentation
Chores