You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Fix 500 on /publisher/[id] when a D1 read fails - #11
/publisher/<id> returned an unhandled HTTP 500. The page called getPublisherProfile() with no try/catch, so when D1 threw, the exception escaped the frontmatter and Cloudflare returned a 500. / stayed 200, which pointed at this route specifically.
Root cause
Reproduced locally by dropping the publishers table (the state an unapplied migration leaves behind):
✘ [ERROR] Error: D1_ERROR: no such table: publishers: SQLITE_ERROR
GET /publisher/clausvalca 500 Internal Server Error
GET / 200 OK
Two things hid it:
The route was null-safe (if (!profile) return 404), but a thrown error never reaches that check — only a returned null does.
Production returned 404, not 500, because its catalog is empty. The empty-data path masked the crash.
The underlying operational gap: nothing in .github/workflows/ applies migrations to remote D1, so a migration can be recorded as applied while its table is missing.
The fix
loadPublisherProfile() returns a tagged result instead of collapsing every failure to null:
Callers now distinguish the two failure modes and render 200 / 404 / 503.
The same unguarded-read pattern is fixed in the other routes that had it: dashboard/publisher/[id], dashboard/settings, api/publishers/[id] (GET and PATCH), and api/user/profile. This matches the convention already used by index.astro, dashboard.astro, plugins.json.ts, and download/[id].ts.
Follow-up commit: resolve the binding inside the guard
CodeRabbit caught a real gap in the first commit. getDB(locals) throws when the DB binding is missing, and it was being evaluated as an argument — before loadPublisherProfile entered its try. So a missing binding still produced a 500, and the comment claiming otherwise was wrong.
Verified by commenting out [[d1_databases]] and rebuilding: /publisher/<id> and /api/publishers/<id> both returned 500.
loadPublisherProfile now also accepts a getter, so resolving the binding happens inside the guarded region:
awaitloadPublisherProfile(()=>getDB(locals),id);// not getDB(locals)
The two PATCH handlers move getDB into their existing try. A plain binding is still accepted, so this only widens the guarded region.
Verification
Every row below was exercised against wrangler pages dev with the built worker, in all three DB states (healthy, table dropped, binding removed):
Scenario
Before
After
Healthy DB, existing publisher
200
200
Healthy DB, missing publisher
404
404
Healthy DB, invalid slug
400
400
publishers table missing (page)
500
503 + fallback
publishers table missing (API)
500
503 JSON
DB binding missing (page)
500
503 + fallback
DB binding missing (API)
500
503 JSON
Homepage in every broken state
200
200
The page shows a real fallback — "Publisher unavailable" with a retry on a server error, "Publisher not found" otherwise.
This stops the 500 but does not restore the feature on production: the remote publishers table is genuinely missing, so the page will now render the 503 fallback. To actually fix the live site:
npm run db:migrate:remote
npm run db:seed:remote # if the catalog is empty
I could not run this — wrangler needs CLOUDFLARE_API_TOKEN for remote access, which isn't available in this environment. The README now documents that migrations are not applied by CI, so the next schema change does not hit the same trap.
This PR was created by an AI agent (OpenHands) on behalf of the user.
Summary by CodeRabbit
Bug Fixes
Publisher and user profile pages now handle database outages gracefully, showing temporary-unavailability responses instead of failing unexpectedly.
Publisher pages distinguish unavailable data from missing profiles and offer a retry option when profile data can’t be loaded.
Settings remain accessible with basic session information when a profile lookup fails.
Documentation
Clarified that remote database migrations must be applied manually and how to check migration status when routes are unavailable.
The publisher page called getPublisherProfile() with no try/catch. When D1
throws — a missing table from an unapplied migration, or an unavailable
binding — the exception escaped the frontmatter and Cloudflare returned an
unhandled 500. Reproduced locally by dropping the publishers table:
D1_ERROR: no such table: publishers: SQLITE_ERROR
GET /publisher/clausvalca -> 500 (GET / stayed 200)
The route was already null-safe, but a thrown error never reaches the null
check. Production returned 404 rather than 500 because its catalog is empty,
so the empty-data path masked the crash.
loadPublisherProfile() now returns a tagged result — ok / not-found / error —
instead of collapsing every failure to null, so callers can tell "no such
publisher" (404) from "the database failed" (503). The page renders a
"Publisher unavailable" fallback with a retry instead of crashing.
The same unguarded read pattern is fixed in the other routes that had it:
dashboard/publisher/[id], dashboard/settings, api/publishers/[id] (GET and
PATCH), and api/user/profile. This matches the convention already used by
index.astro, dashboard.astro, plugins.json.ts and download/[id].ts.
README notes that migrations are not applied by CI, so a schema change needs a
manual `npm run db:migrate:remote` — the state that produced this bug.
Tests: 45 passing (4 new, covering the error / not-found / success paths).
Publisher profile loading now distinguishes database errors from missing publishers. Publisher and user profile paths handle read failures with temporary-unavailability responses or fallback values. The publisher page renders separate unavailable and not-found states.
Changes: Profile Read Handling
Layer / File(s)
Summary
Publisher profile result and tests src/lib/publisher-profile.ts, tests/publisher-profile-page.test.ts, README.md
loadPublisherProfile returns ok, not-found, or error. Tests cover these results and profile composition. The README lists the helper and its test.
Publisher API and page paths return 503 for database errors and retain 404 handling for missing publishers. The public publisher page renders unavailable or not-found content, with a retry button for database errors.
User profile handling and migration notes src/pages/api/user/profile.ts, src/pages/dashboard/settings.astro, README.md
User profile routes return 503 on read errors, while settings uses session-derived fallback values. The README documents manual remote migrations and the 503 fallback for missing tables.
A transient settings read failure can silently overwrite saved profile customizations when the user submits the displayed fallback form; prevent editing until the profile loads successfully.
Pre-merge checks: 4 · 1
Failed checks: 1 warning
Check name
Status
Explanation
Resolution
Docstring Coverage
Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documenta…
Write docstrings for the functions missing them to satisfy the coverage threshold.
Passed checks: 4 passed
Check name
Status
Explanation
Description Check
Check skipped - CodeRabbit’s high-level summary is enabled.
Title check
The title clearly and concisely describes the main change: preventing a 500 response on /publisher/[id] when a D1 read fails.
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage
Explanation
Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 2 functions across 4 files. (4 skipped: 4 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
Recent review info
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: defaults
Review profile: CHILL
Plan: Advanced
Run ID: 66566f32-5782-4cf3-8f3e-f7fd91fee706
Commits
Reviewing files that changed from the base of the PR and between 975e4aa and 9400668.
Files selected for processing: 8
README.md
src/lib/publisher-profile.ts
src/pages/api/publishers/[id].ts
src/pages/api/user/profile.ts
src/pages/dashboard/publisher/[id].astro
src/pages/dashboard/settings.astro
src/pages/publisher/[id].astro
tests/publisher-profile-page.test.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
CodeRabbit caught a real gap: `getDB(locals)` throws when the `DB` binding is
missing, and it was evaluated as an argument — before loadPublisherProfile
entered its try. Both routes still returned 500 for that case, so the comment
claiming "unavailable binding" was covered was wrong.
Verified by removing the [[d1_databases]] block and building: /publisher/<id>
and /api/publishers/<id> both returned 500.
loadPublisherProfile now also accepts a getter, so resolving the binding
happens inside the try. Call sites pass `() => getDB(locals)`; the two PATCH
handlers move `getDB` into their existing try. Same inputs as before — plain
bindings still work — so this is purely a widening of the guarded region.
After: missing binding -> 503 (page fallback + JSON), missing table -> 503,
healthy -> 200/404. Tests: 47 passing (2 new covering the getter path).
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
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.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
What changed
/publisher/<id>returned an unhandled HTTP 500. The page calledgetPublisherProfile()with notry/catch, so when D1 threw, the exception escaped the frontmatter and Cloudflare returned a 500./stayed 200, which pointed at this route specifically.Root cause
Reproduced locally by dropping the
publisherstable (the state an unapplied migration leaves behind):Two things hid it:
if (!profile) return 404), but a thrown error never reaches that check — only a returnednulldoes.The underlying operational gap: nothing in
.github/workflows/applies migrations to remote D1, so a migration can be recorded as applied while its table is missing.The fix
loadPublisherProfile()returns a tagged result instead of collapsing every failure tonull:Callers now distinguish the two failure modes and render 200 / 404 / 503.
The same unguarded-read pattern is fixed in the other routes that had it:
dashboard/publisher/[id],dashboard/settings,api/publishers/[id](GET and PATCH), andapi/user/profile. This matches the convention already used byindex.astro,dashboard.astro,plugins.json.ts, anddownload/[id].ts.Follow-up commit: resolve the binding inside the guard
CodeRabbit caught a real gap in the first commit.
getDB(locals)throws when theDBbinding is missing, and it was being evaluated as an argument — beforeloadPublisherProfileentered itstry. So a missing binding still produced a 500, and the comment claiming otherwise was wrong.Verified by commenting out
[[d1_databases]]and rebuilding:/publisher/<id>and/api/publishers/<id>both returned 500.loadPublisherProfilenow also accepts a getter, so resolving the binding happens inside the guarded region:The two PATCH handlers move
getDBinto their existingtry. A plain binding is still accepted, so this only widens the guarded region.Verification
Every row below was exercised against
wrangler pages devwith the built worker, in all three DB states (healthy, table dropped, binding removed):publisherstable missing (page)publisherstable missing (API)DBbinding missing (page)DBbinding missing (API)The page shows a real fallback — "Publisher unavailable" with a retry on a server error, "Publisher not found" otherwise.
npm run build— cleannpx tsc --noEmit—src/clean (only the pre-existingastro.config.mjsvite-plugin error remains)npm test— 47 passing (6 new: error / not-found / success / empty-profile / throwing-getter / plain-binding)Follow-up required (not in this PR)
This stops the 500 but does not restore the feature on production: the remote
publisherstable is genuinely missing, so the page will now render the 503 fallback. To actually fix the live site:npm run db:migrate:remote npm run db:seed:remote # if the catalog is emptyI could not run this —
wranglerneedsCLOUDFLARE_API_TOKENfor remote access, which isn't available in this environment. The README now documents that migrations are not applied by CI, so the next schema change does not hit the same trap.This PR was created by an AI agent (OpenHands) on behalf of the user.
Summary by CodeRabbit