Skip to content

fix(api): stop a swallowed query error from mis-numbering compositions - #43

Merged
github-actions[bot] merged 1 commit into
mainfrom
fix/composition-version-swallowed-error
Sep 4, 2026
Merged

fix(api): stop a swallowed query error from mis-numbering compositions#43
github-actions[bot] merged 1 commit into
mainfrom
fix/composition-version-swallowed-error

Conversation

@catomean

@catomean catomean commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • POST /api/compositions looked up the latest existing version with const { data: existing } = await supabase...single(), never checking error.
  • .single() throws when zero rows match — the normal case for a project's first composition — so a genuine query failure (RLS misconfig, transient DB outage) left data null exactly like "no composition yet." Both paths silently computed nextVersion = 1, risking an inserted row that collides with or duplicates an existing version instead of surfacing the failure.
  • Switched to .maybeSingle() with an explicit error check, matching this codebase's established convention for "zero rows is a valid outcome" (ownsProject/ownsFigure, and the /api/surfaces and /api/compositions GET handlers fixed in fix(api): stop surfacing DB errors as "no surface/composition yet" #40).
  • Added src/app/api/query-error-checked.test.ts, a structural test that walks every API route for a data destructure bound to an awaited supabase query and fails if the same destructure doesn't also bind error — verified it fails against the pre-fix code and passes after.

Same bug family as #36, #37, #39, #40 (a Supabase query result silently treated as "nothing here" instead of surfacing a real failure) — this closes the one call site those passes missed.

Test plan

  • npm run verify — lint clean (0 errors, 8 pre-existing warnings), tsc clean, 96/96 tests pass
  • Confirmed the new test fails on the pre-fix code (stashed the fix, re-ran — failed at the exact bug line) and passes after

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: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions
github-actions Bot merged commit 9680d3b into main Sep 4, 2026
1 check passed
@github-actions
github-actions Bot deleted the fix/composition-version-swallowed-error branch September 4, 2026 04:14
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant