mirror of
https://github.com/supabase/supabase.git
synced 2026-10-11 04:15:04 +03:00
func-913-compute-agent-docs
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Matt Rossman
|
0d8cd9c315 |
feat(studio): prompt for a higher AI opt-in level instead of "no tool access" (#51411)
## Motivation When an Assistant tool needs a higher opt-in level than the org has, the user only sees the model say it has no access with (inconsistent) written instructions how to fix, instead of Assistant proactively facilitating the fix. <img width="400" alt="CleanShot 2026-10-07 at 3 44 29 PM@2x" src="https://github.com/user-attachments/assets/ba95568a-5db4-4d8c-b4ff-64855f2b87ec" /> The majority of recent labelled [Assistant Issues](https://www.braintrust.dev/app/supabase.io/p/Assistant/topics) in Braintrust are tools or query results blocked by the org opt-in level. We've considered making Assistant disabled entirely when data opt-in is off to eliminate the most common footgun (AI-405), but that's an intrusive change which could break legitimate use cases. ## Changes https://github.com/user-attachments/assets/206a2438-630e-4368-9cec-2b04b66c9cd4 A new `update_opt_in_level` tool renders an inline card which prompts admins to review the opt-in level and highlights the proposed change (non-admins see a message telling them to contact their admin to change the setting). Saving approves the call and the turn resumes at the new level. Results appear in a Braintrust tool span based on https://github.com/supabase/supabase/pull/45654. I added 5 evals that simulate the user answering the opt-in card to verify that the Assistant asks when blocked, continues after the user accepts, and doesn't invent data after a skip. Tool Usage and Correctness are at 100% in the [sample run](https://www.braintrust.dev/app/supabase.io/p/Dev%20(mattrossman%2FAssistant)/experiments/mattrossman%2Fai-158-prompt-users-to-update-settings-instead-of-showing-no-tool-1791483991). <details> <summary>📸 Screenshots</summary> | Admin, pending | Modal, Current and Proposed | | -- | -- | | <img width="100%" alt="CleanShot 2026-10-07 at 3 23 37 PM@2x" src="https://github.com/user-attachments/assets/2fc8ba11-0530-4028-a056-40ca02afd3ef" /> | <img width="1184" height="1754" alt="CleanShot 2026-10-07 at 3 32 37 PM@2x" src="https://github.com/user-attachments/assets/73639633-89ac-4d4c-b869-d9301735d5b9" /> | | **After saving, turn continues** | **Non-admin** | | <img width="100%" alt="CleanShot 2026-10-07 at 3 27 14 PM@2x" src="https://github.com/user-attachments/assets/a91c6760-6dfb-4f51-9ef8-4bdbe1b22495" /> | <img width="100%" alt="CleanShot 2026-10-07 at 3 15 33 PM@2x" src="https://github.com/user-attachments/assets/ecb9aa87-26dc-4b69-a086-cb77a28bb860" /> | </details> ## Verification To test in staging, set your org's Assistant opt-in level to Disabled, ask "What tables do I have?", and review the card. Try selecting the proposed (or different) opt-in level and saving to continue. [This trace](https://www.braintrust.dev/app/supabase.io/p/Dev%20(mattrossman%2FAssistant)/experiments/mattrossman%2Fai-158-prompt-users-to-update-settings-instead-of-showing-no-tool-1791483991?r=90066cd9-4da3-4817-9650-c369d2b42cea) is a sample from the accept eval case after saving Schema Only, note the `update_opt_in_level` span. ## Safety considerations I added a banner to the modal to make it more obvious that this setting impacts the whole org, not just the current chat or project: <img width="592" height="78" alt="CleanShot 2026-10-08 at 2 04 44 PM@2x" src="https://github.com/user-attachments/assets/6b140ed6-65fb-4bc0-b5cc-9c82fe2a67aa" /> I leave the current opt-in value selected by default in the form so the user has to consciously select the proposed value instead of mindlessly clicking save without understanding implications. `execute_sql` and `run_notebook` outputs are now stamped with the level they ran under, and history is sanitized by the least permissive of the stamped vs current opt-in levels. That way raising the level mid-chat doesn't unexpectedly expose earlier query rows to the model. Closes AI-158 |
||
|
Saxon Fletcher
|
e605178a63 |
feat(studio): render assistant log query results (#49293)
<img width="1510" height="862" alt="image" src="https://github.com/user-attachments/assets/f7157bad-9b23-4d73-a9aa-2a7a7c179318" /> ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Feature and bug fix. ## What is the current behavior? `query_logs` can return rows to the assistant, but the chat UI does not hydrate those rows into the query result by default. The query only becomes visible after clicking **Run query**, even though the same SQL and time range work when rerun manually. ## What is the new behavior? - Renders `query_logs` tool output through a dedicated logs message part using the shared assistant query cell. - Parses the exact MCP untrusted-data envelope into the initial query result, without changing what the assistant model receives. - Preserves the logs source and time range for manual reruns. - Infers a useful table or chart presentation from the returned rows while retaining explicit display settings. - Adds focused tests for MCP result parsing, timestamps, errors, query source handling, and visualization inference. ## How to test 1. Check out this PR and run Studio against a project that has recent logs. Generate some project activity first, such as an API request, if needed. 2. Open the AI Assistant and ask: `Show log counts by minute for the last 15 minutes and summarize any spikes.` 3. Wait for `query_logs` to finish. Verify the query cell appears with results already populated; do not click **Run query** first. 4. Verify the aggregate result opens as a chart, then switch to the table view and confirm the underlying rows are present. 5. Click **Run query** and verify the query runs successfully again using the same logs source and 15-minute time range. 6. Ask: `Show the 20 most recent log entries from the last 15 minutes.` Verify this non-aggregate result opens as a table with rows already populated. 7. Confirm the assistant's written summary agrees with the displayed rows and does not report zero rows when results are visible. ## Additional context This is the top PR in stack #49294 and depends on the back-end knowledge change in #49292. Verified with 59 focused tests across assistant context, Studio/MCP tools, query display, and logs result parsing. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added AI Assistant support for querying and displaying application logs. * Added automatic visualization selection, including charts for time-based and categorical data. * Added source-aware query handling with dedicated titles, time ranges, and result displays. * Added clearer loading, parsing, and error states for log queries. * **Bug Fixes** * Improved handling of streamed results, source changes, and query display updates. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
CharisandJoshen Lim
|
8bdfe03fe7 |
refactor(studio): drop notebook type widening now that the API supports it (#49272)
## Summary - Regenerates `packages/api-types` for the content endpoints now that the Platform API's `notebook` content type has landed (list/get/upsert `type` enums, plus `UpsertContentBody`'s notebook cell shape with `_id`/`y_series`). Unrelated schema drift from the same regen (Warehouse, SSO, notification exceptions, etc.) is excluded — only the content-endpoint hunks are applied. - Removes every local widening cast added while the API support was pending (`content-query.ts`, `content-infinite-query.ts`, `notebook-query.ts`, `notebook-upsert-mutation.ts`, `sql-folders-query.ts`). - What remains is scoped and renamed to match: draft ids (`generateDraftId`/`isDraftId`), used only for cells created client-side in the editor before their first save, dropped before they'd ever reach the backend as a fake `_id`. ## Test plan - [x] `pnpm typecheck` — clean - [x] `pnpm --filter studio test` — full suite passes (518 files / 5471 tests) - [x] `pnpm --filter studio run lint:ratchet` — no new warnings - [x] `pnpm format` / prettier — clean <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved notebook cell tracking during editing, reordering, insertion, and deletion. * Preserved existing cell identifiers while removing temporary draft identifiers before saving. * Improved chart configuration for selecting and displaying multiple Y-axis series. * Strengthened notebook validation and content persistence behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Saxon FletcherandCursor
|
6e64ad039c |
feat(studio): add AssistantQueryCell on the shared QueryEditor (#49169)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Feature. ## What is the current behavior? Notebooks and query tabs use `QueryEditor`. Assistant SQL still uses `DisplayBlockRenderer` / `QueryBlock`. ## What is the new behavior? Adds `AssistantQueryCell`, a local-state wrapper around the shared `QueryEditor` (`variant="viewport"`, `isRunDisabled` while confirming). Nothing is wired into the conversation yet — that is #49170 — so this PR is the reusable cell plus the small editor/report-container hooks it needs. ## Additional context Part of stack #49171. Base: `feat/assistant-confirm` (#49168). ## Test plan - [ ] `AssistantQueryCell.utils.test.ts` passes - [ ] Query editor still runs in Explorer notebooks / query tabs - [ ] No assistant conversation UI change in this PR (still DisplayBlockRenderer) --------- Co-authored-by: Cursor <cursoragent@cursor.com> |