Run time errors

[ngoiyaeric]

getSystemPrompt: Error: TypeError: Cannot read properties of undefined (reading 'searchParams')
at (.next/server/chunks/5540.js:7:12448)
at Object.startActiveSpan (.next/server/chunks/5540.js:47:50102)
at (.next/server/chunks/5540.js:7:12284)
at Object.startActiveSpan (.next/server/chunks/5540.js:47:50102)

[ngoiyaeric]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Add defensive error handling at the point where errors are caught (getSystemPrompt) to gracefully handle instrumentation-related errors
• Protect upstream callers (Server Actions) from being affected by these errors through proper null handling and fallbacks
• Review and configure any instrumentation/telemetry to handle missing request context in streaming and async execution contexts
• Ensure auth helpers don't propagate instrumentation errors to application code

Design Choices

Design Choice 1: What is the source of the searchParams access in the compiled code?

Options Considered:

1. The error comes from Next.js built-in instrumentation trying to add request metadata to spans during database operations
2. A third-party telemetry library is instrumenting function calls and accessing request context
3. Drizzle ORM has built-in tracing that requires request context

Chosen Option: 1

Rationale: Next.js instrumentation is the most likely source given the startActiveSpan pattern in the stack trace and the error occurring in .next/server/chunks/. The fix should handle missing request context gracefully rather than requiring context to always be present.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Harden Error Handling in System Prompt Retrieval

This phase focuses on making the getSystemPrompt function more resilient and adding proper error boundaries around its callers to prevent instrumentation errors from affecting application flow.

Task 1: Enhance getSystemPrompt Error Handling

Improve the error handling in the getSystemPrompt function to better categorize errors and provide more context for debugging.

• Update lib/actions/chat.ts to add error type detection in the catch block, distinguishing between instrumentation errors (containing 'searchParams') and actual database errors
• Add structured error logging that includes the error type and whether it's likely an instrumentation issue vs. a genuine failure
• Ensure the function continues to return null gracefully on instrumentation errors while logging appropriately

Task 2: Add Defensive Handling in Server Action Callers

Protect the streaming AI context from being disrupted by these errors.

• Update app/actions.tsx around line 401 where getSystemPrompt is called to add explicit null handling with a fallback empty string
• Verify the existing pattern (await getSystemPrompt(userId)) || '' handles the null return case appropriately
• Add a comment documenting why null returns are expected in certain contexts (instrumentation errors in streaming)

🤖 Prompt for AI agents

This phase makes the `getSystemPrompt` function more resilient to
instrumentation errors and protects its callers from being affected by these
errors.

**Task 1.1: Enhance getSystemPrompt Error Handling**

In `lib/actions/chat.ts`, update the `getSystemPrompt` function's catch block:
- Detect error type by checking if the error message contains 'searchParams' to
identify instrumentation-related errors
- Add structured error logging that distinguishes between:
  - Instrumentation errors (searchParams access failures)
  - Actual database/query errors
- Continue returning `null` gracefully for instrumentation errors
- Log appropriate context for debugging (error type, message, stack trace if
needed)

**Task 1.2: Add Defensive Handling in Server Action Callers**

In `app/actions.tsx` around line 401:
- Verify the `getSystemPrompt` call uses proper null handling with fallback:
`(await getSystemPrompt(userId)) || ''`
- Add explicit null checks if the pattern is different
- Add a code comment explaining that null returns can occur due to
instrumentation errors in streaming contexts and why the fallback is necessary

Phase 2: Configure Instrumentation for Missing Request Context

This phase addresses the root cause by ensuring any Next.js or telemetry instrumentation gracefully handles execution contexts where request properties like searchParams are unavailable.

Task 1: Review and Configure Next.js Instrumentation

Check for and configure any Next.js instrumentation that may be causing the error.

• Check if instrumentation.ts exists in the project root; if present, review its configuration for any telemetry setup that accesses request context
• If using Next.js experimental instrumentation, verify it includes proper guards for accessing request properties
• Add defensive checks to any custom instrumentation code that accesses request.nextUrl.searchParams or similar properties

Task 2: Add Request Context Guards to Auth Helpers

Ensure authentication helpers don't propagate instrumentation errors to callers.

• Update lib/auth/get-current-user.ts to wrap the cookies() call in a try-catch block within getSupabaseUserAndSessionOnServer to handle cases where request context is partially available
• Add error logging specific to auth context issues vs. actual authentication failures
• Ensure getCurrentUserIdOnServer returns null gracefully when request context is unavailable rather than allowing errors to propagate

Task 3: Verify Middleware Configuration

Confirm middleware isn't inadvertently affecting request context availability.

• Review middleware.ts to confirm Server Actions are correctly bypassed via the next-action header check
• Verify no additional middleware processing occurs that could strip or modify request context before Server Actions execute
• Document the middleware bypass pattern for future reference

🤖 Prompt for AI agents

This phase addresses the root cause by configuring instrumentation and auth
helpers to gracefully handle missing request context in streaming and async
execution contexts.

**Task 2.1: Review and Configure Next.js Instrumentation**

- Check for `instrumentation.ts` in the project root
- If it exists:
  - Review any telemetry or tracing configuration
- Add defensive guards around any code accessing `request.nextUrl.searchParams`
or similar request properties
- Ensure instrumentation code checks for property existence before accessing
(e.g., `request?.nextUrl?.searchParams`)
- If using Next.js experimental instrumentation features, verify proper error
boundaries are in place

**Task 2.2: Add Request Context Guards to Auth Helpers**

In `lib/auth/get-current-user.ts`:
- Wrap the `cookies()` call in `getSupabaseUserAndSessionOnServer` with a
try-catch block
- In the catch block:
- Log errors that indicate request context issues separately from authentication
failures
  - Include context about whether this is a streaming/async execution issue
- Ensure `getCurrentUserIdOnServer` returns `null` gracefully when request
context is unavailable
- Prevent instrumentation errors from propagating to application code

**Task 2.3: Verify Middleware Configuration**

In `middleware.ts`:
- Confirm the `next-action` header check correctly bypasses Server Actions
- Verify no middleware logic strips or modifies request context before Server
Actions execute
- Add a code comment documenting the bypass pattern and why it's necessary for
Server Actions to have proper request context

Research

This is a Next.js 15 application using Drizzle ORM for database operations and Supabase for authentication. The getSystemPrompt function in lib/actions/chat.ts queries user system prompts from the database. The error is caught by its existing try-catch block but stems from underlying instrumentation/tracing attempting to access request.searchParams when request context is unavailable—particularly during AI streaming operations in onSetAIState callbacks. The cookies() function from next/headers is used throughout auth helpers, and the middleware explicitly bypasses Server Actions.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase makes the `getSystemPrompt` function more resilient to
instrumentation errors and protects its callers from being affected by these
errors.

**Task 1.1: Enhance getSystemPrompt Error Handling**

In `lib/actions/chat.ts`, update the `getSystemPrompt` function's catch block:
- Detect error type by checking if the error message contains 'searchParams' to
identify instrumentation-related errors
- Add structured error logging that distinguishes between:
  - Instrumentation errors (searchParams access failures)
  - Actual database/query errors
- Continue returning `null` gracefully for instrumentation errors
- Log appropriate context for debugging (error type, message, stack trace if
needed)

**Task 1.2: Add Defensive Handling in Server Action Callers**

In `app/actions.tsx` around line 401:
- Verify the `getSystemPrompt` call uses proper null handling with fallback:
`(await getSystemPrompt(userId)) || ''`
- Add explicit null checks if the pattern is different
- Add a code comment explaining that null returns can occur due to
instrumentation errors in streaming contexts and why the fallback is necessary
===============================================================================

Task: 2

This phase addresses the root cause by configuring instrumentation and auth
helpers to gracefully handle missing request context in streaming and async
execution contexts.

**Task 2.1: Review and Configure Next.js Instrumentation**

- Check for `instrumentation.ts` in the project root
- If it exists:
  - Review any telemetry or tracing configuration
- Add defensive guards around any code accessing `request.nextUrl.searchParams`
or similar request properties
- Ensure instrumentation code checks for property existence before accessing
(e.g., `request?.nextUrl?.searchParams`)
- If using Next.js experimental instrumentation features, verify proper error
boundaries are in place

**Task 2.2: Add Request Context Guards to Auth Helpers**

In `lib/auth/get-current-user.ts`:
- Wrap the `cookies()` call in `getSupabaseUserAndSessionOnServer` with a
try-catch block
- In the catch block:
- Log errors that indicate request context issues separately from authentication
failures
  - Include context about whether this is a streaming/async execution issue
- Ensure `getCurrentUserIdOnServer` returns `null` gracefully when request
context is unavailable
- Prevent instrumentation errors from propagating to application code

**Task 2.3: Verify Middleware Configuration**

In `middleware.ts`:
- Confirm the `next-action` header check correctly bypasses Server Actions
- Verify no middleware logic strips or modifies request context before Server
Actions execute
- Add a code comment documenting the bypass pattern and why it's necessary for
Server Actions to have proper request context

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!