mirror of
https://github.com/supabase/supabase.git
synced 2026-10-13 13:19:09 +03:00
3c305148186c311db7ec03f2e17e91ff94de1200
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Joshen Lim
|
fcfb0f0222 |
Refactor all usage of form.watch to either useWatch or subscribe (#48436)
## Context Replaces all usage of `form.watch()` to use `useWatch` instead + follows the "name what you watch" convention as specified in the react-hook-form skills. There's also a small refactor in `SmtpForm.tsx` which removes the unnecessary use of a `useState` to track if SMTP is enabled or not <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Improvements** * Updated many Studio forms to watch specific fields more precisely, improving live UI updates for previews, warnings, conditional sections, and validation messages. * Enhanced responsiveness across settings, authentication, billing, storage, integrations, and support flows while keeping save/update behavior the same. * **Refined Experiences** * Improved the analytics table creation flow with tighter, enum-based column type validation and structured, type-specific column options. * **Preserved Behavior** * Maintained existing permission checks, submission flows, and account-management workflows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Ali Waseem
|
6d7c3361dc |
fix(studio): hide support access toggle when no project is selected (#48206)
## Summary Support access is granted per-project, but the "Allow support access" toggle stayed visible and submittable even when "No specific project" was selected. This hides the toggle and forces `allowSupportAccess`/`allow_support_access` to `false` in that case, across the standalone support form, sidebar form, and link-ticket form. Addresses [FE-3979](https://linear.app/supabase/issue/FE-3979/support-form-allows-support-access-without-a-project-selected). ## Test plan - [x] Added/updated unit tests in `SupportFormPage.test.tsx` covering toggle visibility and submitted payload when no project is selected - [x] `pnpm vitest run components/interfaces/Support` passes (48 tests) - [x] Typecheck and lint pass on changed files <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Support access is now offered only when a valid project and eligible support category are selected. * Support access is automatically disabled when no specific project is selected. * Form submissions now prevent unsupported support-access requests from being enabled. * **Tests** * Added coverage for project clearing and scenarios without available projects or organizations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Carel de WaalandAlaister Young
|
0acc0eb8b3 |
feat: Support Form - Sync AI assistant conversation to Front (#46778)
# Sync AI assistant conversation to Front ## What & why When a user submits a support ticket, an AI assistant chat opens so they get help immediately while waiting for a human agent. This PR mirrors every turn of that chat into the Front conversation the support form already created, so the support team sees the full context and Front automations (routing, emails, CSAT) can act on it. Studio holds no Front credentials — it calls the platform endpoints (see the platform PR) to do the syncing. The assistant card is gated behind the `supportAssistantFollowUp` ConfigCat flag. ## How it works 1. **Submit** — `SupportFormV3` generates a stable `threadRef` (via the `uuid` package — `crypto.randomUUID()` is `undefined` in insecure contexts like non-localhost HTTP and would throw, silently aborting the submit) and sends it on `/platform/feedback/send`. The response returns the Front `conversationId`. Both are stored on `SubmittedSupportRequest`. 2. **Open chat** — `SupportAssistantSuccessCardContent` opens a chat seeded with `supportMetadata` (`threadRef`, `frontConversationId`, subject, category, severity, …). The first message is a `<support>…</support>` XML block. 3. **First user message** — the chat is tagged `isSupportChat = true`; the `onFinish` hook fires `syncSupportChatToFront`. 4. **Subsequent turns** — each `onFinish` slices the unsynced delta, strips the XML metadata block from the seed message, and posts to the platform messages endpoint. 5. **Escalation / resolve** — the `escalate_to_human` / `resolve_support_conversation` tools (and manual **Escalate**/**Resolve** buttons in the assistant input) flip lifecycle status via `setSupportLifecycleStatus` → `syncSupportLifecycleToFront`, which calls the escalation/resolve endpoints. Front rules act on `ai_support_status`. The assistant only resolves after the user explicitly confirms the issue is fixed. ## Key design decisions - **`threadRef` as the shared key** — one UUID travels as `threadRef` on submit and as `chatId` on every sync, so all messages thread into a single Front conversation. - **`conversationId` from the form response** — passed to all sync/lifecycle calls so the platform skips lazy derivation and PATCHes custom fields directly. - **Delta-only sync** — `lastSyncedMessageCount` tracks what's been sent; the boundary is snapshotted before the async call to avoid skipping messages that arrive mid-flight. - **Server-side de-dup** — stable `external_id` (`chatId:msg.id`) means retries don't duplicate in Front. - **Fire-and-forget** — sync failures log to Sentry, never break the chat; `isSyncing` resets on rehydration so the next `onFinish` retries the same delta. Message and lifecycle syncs use separate guards (`isSyncing` / `isLifecycleSyncing`) so an in-flight message sync can't drop an escalate/resolve. - **Lifecycle queued until the conversation exists** — if a lifecycle transition is requested before the initial message sync has returned a `frontConversationId`, it's stored as `pendingLifecycleStatus` and flushed once the id is assigned, rather than dropped. - **Tools return immediately** — the lifecycle tools return a stub to the AI SDK; the real Front call happens in `onFinish`, keeping async I/O out of the tool execute path. - **XML seed stripped before sync** — only the user's actual `<message>` is sent to Front (or dropped entirely if the form already created the conversation). ## Changes | Area | File(s) | | --- | --- | | Support form state | `SupportForm.state.ts` — `threadRef` / `frontConversationId` on `SubmittedSupportRequest` | | Support form submit | `support-ticket-send.ts` — sends `threadRef`, reads `conversationId` | | Support form UI | `SupportFormV3.tsx` — generates `threadRef`, stores `conversationId` | | AI assistant state | `ai-assistant-state.tsx` — `SupportChatMetadata`, `setSupportLifecycleStatus`, `onFinish` wiring, tool handling | | Message sync | `state/ai-chat-front-sync.ts` — delta tracking, message filtering, initial vs. incremental | | API data layer | `data/feedback/ai-chat-front-sync.ts` — typed platform-client wrappers for the three conversation endpoints | | Support tools | `lib/ai/tools/support-tools.ts` — `escalate_to_human`, `resolve_support_conversation` | | Tool integration | `lib/ai/tool-filter.ts`, `tools/index.ts`, `generate-assistant-response.ts` | | Success card | `SupportAssistantSuccessCardContent.tsx` — tags chat on first engagement | | Assistant panel UI | `AIAssistant.tsx` — Escalate/Resolve buttons, disabled input on closed chats, support placeholders | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit - **New Features** - Support chats now include “Escalate to human” and “Resolve” actions. - Support submissions can be associated with a stable Front thread via a generated `threadRef`, preserving linkage across follow-ups. - AI assistant responses and input hints adapt when support mode is active. - **Bug Fixes** - Improved support chat state management and lifecycle handling to keep conversation metadata and message history synchronized more reliably with Front. - **Chores** - Added/updated coverage to reflect the new support-chat state and syncing behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
Jordi EnricandClaude Sonnet 4.6
|
42ca11f89e |
fix(support): handle rate-limited support submissions gracefully (#46928)
## Problem When a support ticket submission is rejected by the API's rate limiter, the form surfaced the raw server exception text to the user and reported every rejection as an application error. This produced a steady stream of noisy error reports for what is actually expected, recoverable behavior. The rejections are not random: the submit endpoint allows only a small number of requests in a short window, so a quick second submission (a fast retry or a follow-up ticket moments later) gets rejected. The first submission usually succeeds; it's the immediate follow-up that fails. Surfacing the raw error and logging it made this look worse than it is. Separately, the success screen had only top padding, leaving its actions flush against the bottom edge of the card. ## Fix - Detect the rate-limit response and show a clear, friendly message that tells the user how long to wait before trying again, instead of the raw exception text. - Stop reporting rate-limit rejections as errors to our monitoring. They are expected and recoverable, so they no longer add noise. - Give the success state the same vertical padding as the rest of the form so its actions are not flush against the card edge. ## How to test - Open the support form and simulate a 429 from the submit endpoint. - Expected: a friendly message telling the user when they can retry, and no error reported to monitoring. - Submit a ticket successfully and confirm the success screen has even padding above and below its content. ## Notes This covers the user-facing handling. The rate-limit threshold itself is tuned conservatively on the API and can be revisited separately so that ordinary, legitimate resubmissions are not caught. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved support form handling for rate-limited (429) submissions by suppressing unnecessary error reporting while still showing the error and returning the form to editing. * Fixed inconsistent support form spacing so padding is consistent regardless of submission outcome. * **Improvements** * Propagated backend error `code` through the support-ticket submission flow so the UI can react more intelligently to failures (including 429 retry-window messaging). * Enhanced retry timing extraction for rate-limited errors by using `Retry-After` with a fallback to rate-limit reset data. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
Saxon Fletcher
|
033daf223c |
Support form Assistant Streamdown (#46248)
Re-adds support form Assistant response using a lighter weight Streamdown component vs the more heavy `Message` component. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * AI Assistant follow-up card after ticket submission for project-scoped requests. * In-chat support request preview panels showing submitted subject and message. * **Improvements** * Smarter project selection when opening the support form via route/context. * Success screen: cleaner layout, project-name messaging, optional finish action, and a "Join Discord" button. * Category prompt text updated to "What issue are you having?" * New success/feedback section for consistent layouts. * **Tests** * Added tests covering support prompt serialization/parsing and UI previews. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46248?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Joshen Lim
|
d11bd4997e |
Revert "Support form Assistant" (#46194)
Reverts supabase/supabase#45861 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes * **New Features** * Support form now returns to home view upon completion within the help panel. * Success screen conditionally displays community (Discord) section for specific issue categories. * **Bug Fixes** * Improved project selection logic in support form initialization. * **Style** * Updated support form label text for clarity. * Redesigned success screen layout with updated styling and separators. * **Removed Features** * Removed support assistant follow-up card from success screen. * Removed support request message parsing from AI responses. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46194?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Saxon FletcherandGildas Garcia
|
af7d953f52 |
Support form Assistant (#45861)
When a support from is submitted, we believe there is an opportunity to help people before a human receives and responds. Human support is still involved regardless of whether Assistant helps or not, so this is to positioned as a "while you wait" type experience. ## To test: - Enable to `supportAssistantFollowUp` feature flag - Open a project - Open the support form and submit a request - Note the success state and the additional Assistant card - Note text generation in card - Clicking card should open the Assistant conversation <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * AI assistant follow-up card appears after submitting a support ticket to continue the conversation * Support request preview rendered in the assistant panel showing subject/message when present * **Bug Fixes** * Improved project selection fallback during support form initialization * **Improvements** * Refined success layout and messaging; finish action behavior simplified [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/45861) <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com> |
||
|
Saxon FletcherandGildas Garcia
|
4452e0ac2e |
Support form sidebar (#45203)
Refactors our help sidebar within Studio to include the actual support form itself when contact is selected. This PR also cleans up the initial state of the sidebar and the options within. ## To test: - Open an org and click the help icon top right - Click contact support - Submit a support ticket - Click done to return to support sidebar state <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Support form V3 and support sidebar with status button; direct-email helper and URL prefill * Success screen supports onFinish callback and customizable finish label * AI Assistant and Help options accept optional click callbacks; resource items gain keyboard/accessibility support * **Refactor** * Help panel split into home/support views with back navigation * Support components accept flexible align/className props and layout/styling tweaks * Initial URL params loader added for support form * **Tests** * New/updated tests for support flows, success screen, and help options interactions <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com> |
