fix(api): link digest release rows upstream, not to /release/ stubs - #2222
Conversation
#2218 made /release/<id> pages noindexed stubs of upstream content and flipped the web feed's default click to the release's own URL via releaseLinkTarget(). The digest email was never updated, so every release title and version pill still pointed at a page we now Disallow and noindex. Flip digest-email.ts's releaseUrl() to the same policy: upstream http(s) url first, then the slugged webUrl, then the bare-ID path. The upstream url is already on ReleaseLatestItem, so no plumbing changes. The rollup's "and N more" link is untouched — it targets the product page, an org surface rather than a release stub. Also point the admin email sample at a third-party-looking URL so the preview exercises the real path instead of the permalink fallback.
|
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (2)
🚫 Excluded labels (none allowed) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
#2218 turned
/release/<id>pages into noindexed stubs of upstream content (blanketnoindex,Disallow: /release/, sitemap retired) and flipped the web feed's default click to the release's own URL viareleaseLinkTarget()(web/src/lib/release-link.ts). That sweep covered the web feed surfaces only — the digest email was never updated, so every release title and version pill in a sent digest still pointed at a page we've decided is non-canonical.This applies the same policy to the digest.
releaseUrl()inworkers/api/src/lib/digest-email.tsnow resolves upstream-first:Same fallback ladder as
releaseLinkTarget(): upstream http(s)url→ sluggedwebUrl→ bare-ID path (which 308s to canonical). All four call sites inherit it — post title, rollup row, version pill, and theproductPageUrlno-org fallback.No data plumbing needed:
mapLatestRowToReleaseItemalready populates upstreamurlalongsidewebUrl.Notes for reviewers
/{org}/{slug}), an org surface rather than a release stub, so the policy doesn't apply.email-samples.tsfabricatedurl: "https://releases.sh/release/rel_sample_1", which would have made the preview exercise the permalink fallback and render a releases.sh link. Repointed at a third-party-looking changelog URL so the sample is representative.web/src/app/collections/[slug]/digest/[week]/page.tsx:161still emits/release/*paths in schema.orgmentions. That's structured-data metadata pointing at a canonical permalink, which is defensible — not an email link./release/URLs now assert the upstream URL, plus a new test covering both fallback rungs.Checklist
bun run checkpassesbun testpasses (workers/api: 1931 pass, 0 fail)urlandwebUrlalready exist onReleaseLatestItem