fix(marketing): recover downloads from stalled release requests

[leoisadev1]

Problem

A stalled GitHub release request leaves the homepage and download page waiting indefinitely, with download links disabled. Concurrent callers also issue duplicate requests, and unavailable session storage can prevent otherwise valid downloads.

Changes

Bound the complete release request, including body decoding, to five seconds so existing release-page fallback links become usable. Share an in-flight request, retain successful results in memory, tolerate unavailable or invalid session storage, and allow failed requests to retry.

Verification

• All 18 focused release-helper tests passed, including headers/body timeouts, ignored aborts, retries, concurrent calls, and storage failures.
• Targeted lint and marketing production build passed on current main.
• Isolated Chromium exercised / and /download/ at 1280px and 390px. Stalled requests enabled fallback navigation after 5.005–5.015 seconds. Successful requests were shared across routes and reloads; install-dialog close/reopen/Escape and download cancellation passed with no page errors.
• Browser testing ran on the server through its private Tailscale address. No physical laptop or phone was tested.

Before and after

The same stalled GitHub response was observed for 6.5 seconds on unchanged main and this PR. Before, links remain disabled and the page says it is loading. After, the five-second deadline enables the release-page fallback. The recordings use isolated Chromium with identical 1280×900 viewports and fixture requests; no timing overlays or application code were injected.

Before:

After:

Before recording:

prg-release-before.webm

After recording:

prg-release-after.webm

Implemented and verified by gpt-6-astra in T3 Code through the Grok harness.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
akeru-bot-landing	Building	Preview	Sep 8, 2026 7:26pm UTC

[greptile-apps]

Greptile Summary

This PR makes marketing release metadata loading resilient: concurrent download links share one request, stalled response headers or body decoding fall back to the GitHub Releases page after five seconds, and later requests can succeed. The focused release behavior is covered by automated checks.

Confidence Score: 5/5

Safe to merge. The changed release-link behavior was exercised through stalled header and response-body scenarios, fallback clickability, and successful retries.

No defects were established. The focused checks confirm the intended timeout, fallback, shared-request, and retry behavior.

Files Needing Attention: None.

T-Rex Logs

What T-Rex did

• Verified the release-link behavior under stalled response headers and stalled JSON-body decoding, observing that all three download links stayed disabled through 4.85 seconds and then became clickable GitHub Releases fallbacks at about five seconds.
• Confirmed that an aborted request can be retried successfully and that all 18 focused release tests pass after stall-related behavior.
• Compared pre-PR and post-stall behavior, noting that before the PR the links released early due to no request deadline, while after headers stall the links stayed disabled until the fallback and retry paths, with body-stall behavior matching this outcome.

_{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "fix(marketing): recover downloads from s..." | Re-trigger Greptile}