fix(api): stop surfacing DB errors as "no surface/composition yet" - #40
Merged
github-actions[bot] merged 1 commit intoSep 3, 2026
Merged
Conversation
GET /api/surfaces and /api/compositions collapsed every Supabase error
into { success: false, data: null } with no error field. useSurface and
useComposition only throw when success is false AND error is set, so a
real query failure — a transient outage, an RLS misconfiguration — was
indistinguishable from the legitimate "you haven't created one yet"
state. A user who'd already saved a surface, hitting a transient
failure, was silently bounced back to "define your surface" as if the
work had never happened.
Switch both handlers from .single() to .maybeSingle() (already the
project's convention for "zero rows is a valid outcome", per
ownsProject/ownsFigure), which resolves data: null with no error on
zero rows and still surfaces error.message for genuine failures — the
same shape every other route in the app already uses.
Added a structural test that walks every API route's
NextResponse.json({ success: false, ... }) call site and fails on any
missing an error field, so this class of bug can't come back by hand.
github-actions
Bot
deleted the
fix/surface-composition-error-swallowing
branch
September 3, 2026 04:06
2 tasks
github-actions Bot
pushed a commit
that referenced
this pull request
Sep 4, 2026
#43) POST /api/compositions computed nextVersion from `{ data: existing } = await supabase...single()` without checking `error`. `.single()` throws on zero rows — the normal case for a project's first composition — so a real query failure (RLS misconfig, DB outage) left `data` null just like "no composition yet," silently defaulting nextVersion to 1 instead of surfacing the failure and risking a colliding/duplicate version. Switched to `.maybeSingle()` with an explicit error check, matching the project's convention for "zero rows is valid" (ownsProject/ownsFigure, the surfaces/compositions GET handlers from #40). Added a structural test that walks every API route for a `data` destructure from a supabase query missing its `error`, so a call site can't drop back to this pattern. Co-authored-by: Mao Nakamoto <maonakamoto@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
3 tasks
github-actions Bot
pushed a commit
that referenced
this pull request
Sep 5, 2026
) Upsert deleted the existing surface before inserting the new one but never checked the delete's result. If the delete silently failed (RLS misconfig, transient DB error), the insert left two rows for one project, and every later GET for that surface would 500 since it relies on .maybeSingle() expecting at most one row. Same unchecked-error family as PR #36/#37/#39/#40/#43. Co-authored-by: Mao Nakamoto <maonakamoto@users.noreply.github.com>
3 tasks
github-actions Bot
pushed a commit
that referenced
this pull request
Sep 6, 2026
ownsProject/ownsFigure discarded the Supabase error from their select() calls and returned false whenever data came back null — which is also what happens on a real query failure (RLS misconfig, DB outage). Every route's authorization check then reported "Not found" instead of surfacing a server error, same bug class as #40 but one layer down in the shared ownership helper, affecting every POST/PATCH/DELETE (and several GETs) across surfaces, compositions, and figures. ownsProject/ownsFigure now return { owns, error } so callers can tell a real failure (500) apart from "caller doesn't own this" (404). Co-authored-by: Mao Nakamoto <maonakamoto@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GET /api/surfacesandGET /api/compositionscollapsed every Supabase error (a real DB outage, an RLS misconfiguration — not just "no row yet") into{ success: false, data: null }with noerrorfield.useSurface/useCompositiononly throw when!success && error, so a genuine query failure resolved clean todata: null, indistinguishable from "you haven't saved one yet" — a user who already saved a surface could get silently bounced back to "define your surface" on a transient failure, believing their work vanished..single()to.maybeSingle()— already this codebase's convention for "zero rows is a valid outcome" (seeownsProject/ownsFigure) — which returnsdata: nullwith no error on zero rows, and still forwardserror.messagefor genuine failures, matching every other route in the app.src/app/api/error-shape.test.ts) that walks every API route'sNextResponse.json({ success: false, ... })call site and fails on any missing anerrorfield, in the same spirit as the existingmutations-report-failure.test.tsguard.Test plan
npm run verify(lint + typecheck + vitest) — all green, 89/89 testsgit stash+ run) and passes after the fix🤖 Generated with Claude Code