[only21mil]

Problem

The download page reads the latest release from the GitHub API in the visitor's browser. Unauthenticated requests are limited per IP, so visitors behind a shared address can get a 403 or 429. fetchStable in apps/marketing/src/lib/releases.ts parsed that error body as if it were a release and never checked response.ok. The page's error branch, which shows "Releases", never ran. Instead the missing tag_name was written into the version label, so the Stable tab showed a lone arrow with no text. The download cards still pointed at the releases page, so the only visible damage was the blank label.

Change

A small fetchJson helper throws when the response isn't OK, and both the Stable and Nightly fetches use it. The page's existing catch then shows "Releases", and the cards keep their releases-page links. Nightly already ended in that branch, because an error body isn't an array; it now just gets a clearer error. The homepage shares this loader and already falls back to the releases page, so it looks the same either way.

apps/marketing had no tests. The new test sits next to releases.ts, and the package gets a test script so CI runs it. Open #24577 adds the identical "test": "vp test run" line, so the two merge cleanly in either order.

Scope and approval

There is no issue. This is a small, focused fix for an obvious bug: a failed request is now treated as a failure. Nothing else about the page changes.

Prior PRs

#4909 by @maria-rcks added the same response.ok check inside a full marketing redesign. It closed unmerged, as did the related redesign PRs #5296, #5452 and #5457, which carried the same check. This PR carries only that check.

Verification

• releases.test.ts stubs fetch with a 403 rate-limit body. It fails on main, where the body comes back as a release, and passes here.
• vp run check:changed passes.
• I built the site from main and from this branch and captured /download in headless Chromium. Every request to the GitHub releases API returned a synthetic 403 rate-limit response.

Before (main, Stable): the version label under the channel toggle is blank, leaving only the arrow.

After (Stable): the label reads "Releases" and links to the releases page.

The Nightly tab showed "Releases" before and after, and every download card kept its releases-page link in both builds.

Generated with Claude Opus 5.5 and GPT-6.1 Terra in T3 Code Nightly

[macroscopeapp]

Approvability

Verdict: Approved at 559370b

Macroscope's review found this PR approvable — Unsuccessful GitHub API responses now trigger the existing Releases fallback instead of being treated as release data. Successful downloads and release-channel defaults remain unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 5fe18d7
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: e72c5f79-9f54-47e0-937b-15c2948f3229

Commits

Reviewing files that changed from the base of the PR and between 5fe18d7 and 559370b.

Files selected for processing: 3

• apps/marketing/package.json
• apps/marketing/src/lib/releases.test.ts
• apps/marketing/src/lib/releases.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 5 remain after this review.

Walkthrough

Release fetches now check HTTP response status before parsing JSON. The marketing package adds a test script and a test that verifies a 403 response causes fetchLatestRelease("stable") to reject with an error containing the status.

Changes: Release fetch HTTP status handling

Layer / File(s)	Summary
HTTP status checks and test apps/marketing/src/lib/releases.ts, apps/marketing/src/lib/releases.test.ts, apps/marketing/package.json	A shared helper throws an error when a response is not OK and parses JSON otherwise. Both stable and nightly release fetches use the helper. A test checks the 403 error, and the package adds a test script that runs vp test run.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#24577: Adds the same marketing package test script, alongside a mobile store-routing change.

Suggested labels: bugfix, size:S

Suggested reviewers: t3dotgg, macroscopeapp

Merge Risk: Minimal · up to 55937

The change correctly routes failed release API responses to the existing Releases fallback and adds focused 403 coverage.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the marketing download page bug and the expected Releases fallback when the GitHub API rejects a request.
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.
Description check		The pull request description includes all required sections. It clearly explains the problem, the implementation, scope justification, focused test coverage, manual verification, observed results, scr…

Full details: Description check

Explanation

The pull request description includes all required sections. It clearly explains the problem, the implementation, scope justification, focused test coverage, manual verification, observed results, screenshots, and agent attribution.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified unchanged head 559370bd099517122c3a9cc0c57e9f9f50232d4a against github/main at 8b74a69019, using separate checkouts, vp i, and one astro marketing dev server at a time. drove /download with the repository’s playwright and /usr/bin/google-chrome on linux.

github returned real unauthenticated 403 rate-limit responses after real api requests exhausted the quota. no request interception, mocked fetch, synthetic responses, fixtures, or demo data were used.

• main: stable showed an empty version label beside the arrow.
• pr: the same 403 showed Releases; all seven desktop asset links retained the stable releases fallback.
• nightly: 403 showed Releases and the nightly releases links. switching back restored stable links and its Releases label.
• homepage: rejected requests retained the releases fallback.
• after the quota reset: real 200 responses showed stable v0.1.6 and nightly’s build age, with real release asset links. toggling and reloading reused session cache: exactly two api requests for both channels. the changelog opened the release page, and the homepage linux download targeted the release asset.

vp test run apps/marketing/src/lib/releases.test.ts passed on blacksmith. vp run check:changed 5fe18d79ac835e0f193ad61325e5b7d69a317bcf also passed there after fetching the pr ancestry into the shallow worker. no source changes or pushes were needed.

short runtime transcript

Not verified

429 specifically was not induced; the live failure check used github’s actual 403 response. native clients and downloaded installers were not exercised on this linux vm. codex turns and projects are outside this change: the affected marketing page fetches github releases directly in the browser and does not use the agent server or a provider.