System prompts

[ngoiyaeric]

System prompts are not saving.

[ngoiyaeric]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• Decouple the shared Settings form validation so an unrelated field, such as domain, cannot silently block the systemPrompt save, and surface any blocked submit with a toast.
• Make resolveClerkUserToDbUser idempotent so a first-login race cannot resolve to null and drop the save.
• Correct revalidatePath in saveSystemPrompt (and therefore deleteSystemPrompt) to the routes that render prompt-dependent content.

File-level change notes for follow-up agents

• components/settings/components/settings.tsx: change domain to z.string().optional(); add a Zod preprocess/transform on each users entry role that coerces missing/null/unknown values to "viewer"; add an onInvalid handler to form.handleSubmit that shows a destructive toast titled "Validation Error" and names each invalid field with its label and tab.
• components/settings/components/system-prompt-form.tsx: in the "Generate from domain" flow only, trim the domain string, then prepend https:// when the string has no http:///https:// scheme.
• lib/auth/get-current-user.ts: convert the INSERT in resolveClerkUserToDbUser to a conflict-safe upsert with re-select; narrow the catch to avoid returning null on a recoverable conflict.
• lib/actions/chat.ts: replace revalidatePath('/settings') in saveSystemPrompt with revalidatePath('/') and revalidatePath('/search/[id]', 'page'); this also fixes deleteSystemPrompt, which calls saveSystemPrompt.
• Note: the plural system_prompts table in lib/db/schema.ts is unused by this feature. Do not wire it in for this ticket. Leave it unchanged unless a separate cleanup ticket covers it.

Design Choices

Design Choice 1: Which defect is the primary cause of the reported symptom?

Options Considered:

1. Shared form validation blocks submit. An invalid domain value (a bare host such as example.com) fails z.string().url(). form.handleSubmit never calls onSubmit. No toast appears. The systemPrompt save never runs.
2. First-login user-resolution race. Concurrent requests hit the non-atomic INSERT in resolveClerkUserToDbUser. The losing request gets a unique-constraint error, the catch returns null, and saveSystemPrompt returns { error: 'User ID is required' }, so the write is dropped.
3. Wrong revalidatePath target. saveSystemPrompt calls revalidatePath('/settings'), a route that does not exist. Server components that read users.system_prompt on / and /search/[id] keep stale content after a successful write.

Chosen Option: 1

Rationale: The ticket does not include reproduction steps. Exploration found three independent causes. The fix must cover all three, because each produces the same user-visible result. All three: they are non-overlapping and each is a real defect that maps to the reported symptom, so the plan addresses each one.

💡 User Tips

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

Implementation Steps

Phase 1: Make the Settings form save the system prompt reliably

This phase removes the validation coupling that silently blocks the save, and makes any validation failure visible. The goal is that a valid system prompt always reaches the server action, and any blocked submit produces clear feedback.

Task 1: Stop unrelated fields from blocking the system prompt save

Decouple sibling-field validation from the prompt save path.

• In components/settings/components/settings.tsx, change the domain field in the shared settingsFormSchema to exactly z.string().optional(). Do not use a lenient host regex in the schema. The domain field only feeds the optional "Generate from domain" flow, so the schema must not reject any value.
• Do not add URL-prefix normalization to the shared schema. Perform all normalization only in the "Generate from domain" flow.
• In components/settings/components/system-prompt-form.tsx, normalize the domain value only inside the "Generate from domain" flow. First trim whitespace from the domain string. Then check for an http:// or https:// scheme. If the string has no scheme, prepend https:// before the generation flow uses it.
• For the users array in settingsFormSchema, coerce role values before validation. Add a Zod preprocess (or transform) step on each entry's role that maps a missing, null, unknown, or out-of-enum value to "viewer" before the z.enum(["admin","editor","viewer"]) check runs. This prevents one legacy row from blocking the whole form if a later change wires getUsers() into defaults.
• Rationale: the shared zodResolver currently rejects the entire form when one unrelated field is invalid, which drops the systemPrompt save with no visible error.

Task 2: Surface validation failures to the user

Make a blocked submit produce feedback instead of silence.

• In components/settings/components/settings.tsx, pass an error callback to form.handleSubmit(onSubmit, onInvalid).
• In onInvalid, show a toast with title "Validation Error" and destructive styling.
• In the toast description, name each invalid field by its friendly label and state which tab it is on. Use the format "Business Domain on System tab is invalid". List each invalid field, because Radix Tabs.Content unmounts inactive tabs and hides their FormMessage.
• Rationale: today an invalid field on a hidden tab shows nothing, so the user believes the save silently failed.

🤖 Prompt for AI agents

Implement Phase 1: make the Settings form save the system prompt reliably by
removing validation coupling that silently blocks the save, and by making any
validation failure visible to the user.

1. In `components/settings/components/settings.tsx`, change the `domain` field
in the shared `settingsFormSchema` to exactly `z.string().optional()`:
- Do not use a lenient host regex in the schema. The `domain` field only feeds
the optional "Generate from domain" flow, so the schema must not reject any
value.
- Do not add URL-prefix normalization to the shared schema. Perform all
normalization only in the "Generate from domain" flow.
- In `components/settings/components/system-prompt-form.tsx`, normalize the
`domain` value only inside the "Generate from domain" flow: first trim
whitespace, then check for an `http://` or `https://` scheme, and prepend
`https://` if no scheme is present, before the generation flow uses the value.
- For the `users` array in `settingsFormSchema`, add a Zod `preprocess` (or
`transform`) step on each entry's `role` that maps a missing, `null`, unknown,
or out-of-enum value to `"viewer"` before the
`z.enum(["admin","editor","viewer"])` check runs. This prevents one legacy row
from blocking the whole form if a later change wires `getUsers()` into defaults.
- Rationale: the shared `zodResolver` currently rejects the entire form when one
unrelated field is invalid, which drops the `systemPrompt` save with no visible
error.

2. In `components/settings/components/settings.tsx`, pass an error callback to
`form.handleSubmit(onSubmit, onInvalid)`:
- In `onInvalid`, show a toast with title `"Validation Error"` and destructive
styling.
- In the toast description, name each invalid field by its friendly label and
state which tab it is on, using the format `"Business Domain on System tab is
invalid"`. List each invalid field, because Radix `Tabs.Content` unmounts
inactive tabs and hides their `FormMessage`.
- Rationale: today an invalid field on a hidden tab shows nothing, so the user
believes the save silently failed.

Phase 2: Prevent dropped saves from user-resolution races

This phase makes the Clerk-to-internal-user mapping return a stable id under concurrent first-login requests. The goal is that saveSystemPrompt never receives null for an authenticated user.

Task 1: Make user creation idempotent

Replace the non-atomic SELECT-then-INSERT with a conflict-safe write.

• In lib/auth/get-current-user.ts, change the INSERT branch in resolveClerkUserToDbUser to an idempotent upsert. Use Drizzle onConflict handling on the clerk_user_id unique constraint (and the email unique constraint) so a concurrent insert does not throw.
• After a conflict, re-run the SELECT by clerk_user_id and return the existing row id. Do not return null when the row already exists.
• Keep the email-link branch, but only link when the existing row has a null clerk_user_id, as it does today.
• Rationale: the current generic catch turns a unique-constraint race into null, which makes saveSystemPrompt return { error: 'User ID is required' } and drop the write.

Task 2: Narrow error handling so real failures are not hidden

Distinguish an expected conflict from an unexpected error.

• In lib/auth/get-current-user.ts, after Task 2.1, treat a unique-constraint conflict as a recoverable case that re-selects and returns the id. Log and re-raise or return null only for genuinely unexpected errors.
• Rationale: the current catch-all masks distinct failures behind one null return, which hides the true cause of dropped saves.

🤖 Prompt for AI agents

Implement Phase 2: prevent dropped saves caused by user-resolution races, so
`saveSystemPrompt` never receives `null` for an authenticated user.

1. In `lib/auth/get-current-user.ts`, change the INSERT branch in
`resolveClerkUserToDbUser` to an idempotent upsert:
- Use Drizzle `onConflict` handling on the `clerk_user_id` unique constraint and
on the `email` unique constraint so a concurrent insert does not throw.
- After a conflict, re-run the SELECT by `clerk_user_id` and return the existing
row id. Do not return `null` when the row already exists.
- Keep the email-link branch, but only link when the existing row has a `null`
`clerk_user_id`, as it does today.
- Rationale: the current generic catch turns a unique-constraint race into
`null`, which makes `saveSystemPrompt` return `{ error: 'User ID is required' }`
and drop the write.

2. In `lib/auth/get-current-user.ts`, after implementing the upsert, narrow the
error handling:
- Treat a unique-constraint conflict as a recoverable case that re-selects and
returns the id.
   - Log and re-raise, or return `null`, only for genuinely unexpected errors.
- Rationale: the current catch-all masks distinct failures behind one `null`
return, which hides the true cause of dropped saves.

Phase 3: Correct cache revalidation after a save

This phase fixes the revalidation target so downstream server-rendered content reflects a saved prompt.

Fix the revalidatePath targets in the prompt actions

Point revalidation at the routes that actually render prompt-dependent content.

• In lib/actions/chat.ts, update saveSystemPrompt to revalidate the real routes. Remove the revalidatePath('/settings') call, because no /settings route exists.
• Add revalidatePath('/') for the home route. Add revalidatePath('/search/[id]', 'page') for the dynamic search route. Use the 'page' type argument for the dynamic segment, because Next.js requires the type argument to invalidate a dynamic route pattern.
• This fix must cover both the save flow and the delete flow. deleteSystemPrompt calls saveSystemPrompt, so the corrected revalidatePath calls in saveSystemPrompt also apply to deletes. Verify that a delete revalidates the same / and /search/[id] routes as a save.
• Rationale: server components read users.system_prompt on / and /search/[id]. The current target never invalidates their cache, so prompt-dependent output can stay stale after a successful write or delete.

🤖 Prompt for AI agents

Implement Phase 3: correct the cache revalidation target so downstream
server-rendered content reflects a saved system prompt.

1. In `lib/actions/chat.ts`, update `saveSystemPrompt` to revalidate the real
routes:
- Remove the `revalidatePath('/settings')` call, because no `/settings` route
exists.
   - Add `revalidatePath('/')` for the home route.
- Add `revalidatePath('/search/[id]', 'page')` for the dynamic search route,
using the `'page'` type argument, because Next.js requires the type argument to
invalidate a dynamic route pattern.

2. Cover both the save flow and the delete flow:
- `deleteSystemPrompt` calls `saveSystemPrompt`, so the corrected
`revalidatePath` calls in `saveSystemPrompt` also apply to deletes.
- Verify that a delete revalidates the same `/` and `/search/[id]` routes as a
save.
- Rationale: server components read `users.system_prompt` on `/` and
`/search/[id]`. The current target never invalidates their cache, so
prompt-dependent output can stay stale after a successful write or delete.

Research

The Settings UI renders SystemPromptForm, ToolSelectionForm, and UserManagementForm inside a single shared react-hook-form in components/settings/components/settings.tsx. The prompt persists through the server action saveSystemPrompt in lib/actions/chat.ts, which writes the users.system_prompt column with Drizzle over a direct Postgres connection. The action resolves the current user through getCurrentUserIdOnServer in lib/auth/get-current-user.ts, which maps a Clerk ID to an internal users.id UUID with a non-atomic SELECT-then-INSERT. The system_prompts table and its RLS policies are unused by this feature. Exploration found three concrete defects that can each produce the "not saving" symptom.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: make the Settings form save the system prompt reliably by
removing validation coupling that silently blocks the save, and by making any
validation failure visible to the user.

1. In `components/settings/components/settings.tsx`, change the `domain` field
in the shared `settingsFormSchema` to exactly `z.string().optional()`:
- Do not use a lenient host regex in the schema. The `domain` field only feeds
the optional "Generate from domain" flow, so the schema must not reject any
value.
- Do not add URL-prefix normalization to the shared schema. Perform all
normalization only in the "Generate from domain" flow.
- In `components/settings/components/system-prompt-form.tsx`, normalize the
`domain` value only inside the "Generate from domain" flow: first trim
whitespace, then check for an `http://` or `https://` scheme, and prepend
`https://` if no scheme is present, before the generation flow uses the value.
- For the `users` array in `settingsFormSchema`, add a Zod `preprocess` (or
`transform`) step on each entry's `role` that maps a missing, `null`, unknown,
or out-of-enum value to `"viewer"` before the
`z.enum(["admin","editor","viewer"])` check runs. This prevents one legacy row
from blocking the whole form if a later change wires `getUsers()` into defaults.
- Rationale: the shared `zodResolver` currently rejects the entire form when one
unrelated field is invalid, which drops the `systemPrompt` save with no visible
error.

2. In `components/settings/components/settings.tsx`, pass an error callback to
`form.handleSubmit(onSubmit, onInvalid)`:
- In `onInvalid`, show a toast with title `"Validation Error"` and destructive
styling.
- In the toast description, name each invalid field by its friendly label and
state which tab it is on, using the format `"Business Domain on System tab is
invalid"`. List each invalid field, because Radix `Tabs.Content` unmounts
inactive tabs and hides their `FormMessage`.
- Rationale: today an invalid field on a hidden tab shows nothing, so the user
believes the save silently failed.
===============================================================================

Task: 2

Implement Phase 2: prevent dropped saves caused by user-resolution races, so
`saveSystemPrompt` never receives `null` for an authenticated user.

1. In `lib/auth/get-current-user.ts`, change the INSERT branch in
`resolveClerkUserToDbUser` to an idempotent upsert:
- Use Drizzle `onConflict` handling on the `clerk_user_id` unique constraint and
on the `email` unique constraint so a concurrent insert does not throw.
- After a conflict, re-run the SELECT by `clerk_user_id` and return the existing
row id. Do not return `null` when the row already exists.
- Keep the email-link branch, but only link when the existing row has a `null`
`clerk_user_id`, as it does today.
- Rationale: the current generic catch turns a unique-constraint race into
`null`, which makes `saveSystemPrompt` return `{ error: 'User ID is required' }`
and drop the write.

2. In `lib/auth/get-current-user.ts`, after implementing the upsert, narrow the
error handling:
- Treat a unique-constraint conflict as a recoverable case that re-selects and
returns the id.
   - Log and re-raise, or return `null`, only for genuinely unexpected errors.
- Rationale: the current catch-all masks distinct failures behind one `null`
return, which hides the true cause of dropped saves.
===============================================================================

Task: 3

Implement Phase 3: correct the cache revalidation target so downstream
server-rendered content reflects a saved system prompt.

1. In `lib/actions/chat.ts`, update `saveSystemPrompt` to revalidate the real
routes:
- Remove the `revalidatePath('/settings')` call, because no `/settings` route
exists.
   - Add `revalidatePath('/')` for the home route.
- Add `revalidatePath('/search/[id]', 'page')` for the dynamic search route,
using the `'page'` type argument, because Next.js requires the type argument to
invalidate a dynamic route pattern.

2. Cover both the save flow and the delete flow:
- `deleteSystemPrompt` calls `saveSystemPrompt`, so the corrected
`revalidatePath` calls in `saveSystemPrompt` also apply to deletes.
- Verify that a delete revalidates the same `/` and `/search/[id]` routes as a
save.
- Rationale: server components read `users.system_prompt` on `/` and
`/search/[id]`. The current target never invalidates their cache, so
prompt-dependent output can stay stale after a successful write or delete.

💡 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.

---

[ngoiyaeric]

@coderabbitai plan Hello! I have carefully analyzed the tasks for Phase 1, Phase 2, and Phase 3. Before I set the execution plan, I want to confirm a few assumptions with you:

Domain schema & normalization (Phase 1):

In settingsFormSchema, we will make domain: z.string().optional().
In SystemPromptForm, when calling startSystemPromptGeneration(domain), if domain does not start with http:// or https://, we will prepend https:// (e.g., https://${domain.trim()}). Does this align with your expectations for domain normalization?
Validation Error Toast in onInvalid (Phase 1):

When form validation fails on hidden or visible tabs, onInvalid will trigger a destructive toast.
For example: Title: "Validation Error", Description listing the failing field(s) with their user-friendly label and the tab they are located on (e.g., "Field 'Business Domain' on System tab is invalid"). Is this toast message structure acceptable, or do you have specific text requirements for the toast?
User Role Coercion (Phase 1):

In settingsFormSchema, for the users array, we will use a schema transformation (e.g. z.preprocess) so that if a role is unknown, null, or out-of-enum, it defaults/coerces to "viewer" before validation rather than failing schema validation. Does this match what you envisioned for legacy user rows?
Revalidation Routes in saveSystemPrompt (Phase 3):

In lib/actions/chat.ts, we will remove revalidatePath('/settings') and replace it with revalidatePath('/') and revalidatePath('/search/[id]'). Should revalidatePath('/search/[id]') be called literally as '/search/[id]' for the dynamic route segment?
Please let me know if these assumptions are correct or if you have any preferences!

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!