[build] Remove live per-mention Typesense fan-out from blog prerendering

[viktor-shcherb]

Audit finding

A correctly configured production web build depends on and amplifies calls to live production Typesense while prerendering blog content.

Observed during the 2026-08-03 audit:

• generateStaticParams prerendered every blog slug across four locales (184 static pages in this build);
• MDX contained 188 <Company>/<CompanyCard> mention call sites, representing 25 unique company slugs across locales;
• MdxMentions.tsx resolves each distinct (slug, locale) through live getCompanyBySlug;
• React cache() deduplicates only within a render, not across all prerendered pages/locales;
• the build rapidly received sustained Typesense 503 and then Cloudflare 429 responses;
• nested retry behavior produced dozens of attempt 4/5 calls;
• the audit stopped the build at static page 138/184 to avoid further production load.

This is independent of the intentionally incorrect-env diagnostic run. The correctly ordered main-repository credentials reproduced the live dependency and request amplification.

Impact

• Web deploys can fail or stall when the search plane is degraded.
• A deploy/build can add significant load to an already unhealthy production dependency.
• Per-IP rate limits turn valid build traffic into a retry storm.
• Raw client-error logging made this path expose credentials before [security] Stop logging Typesense credentials in raw client errors and rotate exposed keys #6123.
• Static blog content is coupled to live mutable infrastructure despite most mention identity data being stable.

Scope

• Inventory all build-time external calls and classify which are allowed.
• Resolve company mentions through one bounded/bulk/static build input rather than per-component live lookups.
• Deduplicate across pages and locales for the whole build.
• Do not stack application retries beneath framework prerender concurrency.
• Make blog builds deterministic and able to complete during Typesense unavailability.
• Add concurrency, request-budget, and failure-mode guards.
• Test with a local fixture/fake service; CI must not hammer production.
• Preserve an explicit missing-mention signal for authors without failing every deployment.

Acceptance criteria

• A full four-locale build makes a documented bounded number of company-resolution calls (preferably zero live production calls).
• Each unique mention is resolved at most once per approved data source/build snapshot.
• A Typesense 503/429 simulation completes or fails fast without retry amplification.
• Production build/deploy does not require search-plane availability.
• CI asserts the external-call budget and blocks production-host calls in tests.
• Build logs contain no credentials or raw client configuration.
• Blog mention output remains correct for all locales and missing slugs.

Related

• [critical] Recover Typesense from persistent leaderless Raft state and prevent descriptor exhaustion #6119
• [security] Stop logging Typesense credentials in raw client errors and rotate exposed keys #6123
• audit-observability: web app emits zero metrics; Typesense vs Postgres fallback ratio is unmeasurable #3182

Found during the 2026-08-03 full repository/service audit. Murmur, Stripe, and Resend are outside scope.

[viktor-shcherb]

Broader production evidence from the infra lane: the latest two Vercel production deployment attempts failed while static generation encountered Typesense 503 and an upstream HTTP 429; the previously promoted deployment continued serving /en with HTTP 200 (0.22 s). The issue scope should cover all build-time external reads and simulate 429/timeout/503, not only the currently proven MDX-company call site. Re-run the failed commits after decoupling and identify the 429 source before assigning provider-specific blame.