fix(routing): open what the release announcement links to, on a stable id - #182
Merged
Conversation
…e id 278 links across the news open the pathway browser with nothing in it -- 21 of them in the current release's own announcement, which is the list of what is new in v97. They are written the way the old browser addressed a pathway: a bare dbId in the fragment, `/PathwayBrowser/#1280218`. #172 taught the pattern to read `#R-HSA-…`, and these are the other half of the same legacy. The browser already resolves a dbId given in the path, so only the fragment form was missing. **But it does not leave the reader on one.** A dbId is not stable across releases, so a URL carrying one is a URL not worth keeping or sharing, and an old link should hand over a good one. The dbId is resolved to its stable id and that is what is navigated to: `#1280218` now lands on `/PathwayBrowser/R-HSA-1280218`. If the lookup fails it falls back to the dbId, which loads -- a page on a worse URL beats a link that goes nowhere, and refusing to navigate would turn a working legacy link into a dead one. Four digits at least, so an ordinary page anchor cannot be taken for a dbId; the shortest one in the content is five, and there are no shorter numeric fragments in it. This also closes the last **gap** row in RELEASE-TESTING.md, which asked a person to check that "a newly added pathway, reaction and complex render" every release. The announcement names them, so `e2e/release/new-in-this-release.spec.ts` reads the newest release note in the repo and opens each link exactly as written -- 21 for v97, all of them now -- and asserts each lands on a stable id. That leaves 48 auto, 8 human, 2 missing and no gaps. Still written as dbIds in the content itself, which is a separate question: 13 curated files, and the announcements are authored through the CMS. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adamjohnwright
enabled auto-merge (squash)
September 9, 2026 17:15
adamjohnwright
added a commit
that referenced
this pull request
Sep 9, 2026
An adversarial pass over #172 and #182. **Following a legacy link trapped the reader.** From the news archive, opening `/PathwayBrowser/#1280218` and pressing Back stayed on the pathway -- six times over. The rewrite is the cause: the app writes state into the URL while the fragment is still there, so `/PathwayBrowser#1280218` and `?tab=details#1280218` both became history entries carrying it, and going back to such an entry rewrites it forward again. Both PRs shipped this; the `#R-HSA-…` links have had it since #172. Two changes. A fragment being consumed is no longer carried forward by the navigations that write state into the URL, so no entry retains it. And a dbId is navigated on immediately rather than after its lookup -- going first means the fragment is consumed in the same turn as a stable-id one, before anything else can record it -- with the URL then corrected to the stable id by a replace, which adds no entry. Measured from /about/news: a dbId link now takes 3 Backs to leave, a stable-id link 4, and a direct load 3. It was never. **I had also written a resolver that already existed.** `dbIdToStId` has been on this service all along, unused, and it is the better one: it asks `/data/query/<dbId>/stId` and gets 13 bytes, where mine fetched the whole object for one field -- 12,682. Mine is gone and the existing one has its first caller. Not fixed, and not mine: a pathway load adds two history entries of its own before any of this, which is why leaving still takes three Backs rather than one. Every navigation in this service pushes, including the ones that are only normalising the URL. Worth a look, but making them replace would also stop Back working between pathways, so it needs deciding rather than just changing. The escape is now a test, because it broke twice without anything noticing. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
278 links across the news open the pathway browser with nothing in it — 21 of them in the current release's own announcement, which is the list of what's new in v97.
270-v92-news.mdx275-v93-released.mdx291-v96-released.mdx295-v97-released.mdxThey're written the way the old browser addressed a pathway — a bare dbId in the fragment,
/PathwayBrowser/#1280218. #172 taught the pattern to read#R-HSA-…; these are the other half of the same legacy. The browser already resolves a dbId given in the path, so only the fragment form was missing.But it does not leave the reader on one
A dbId is not stable across releases, so a URL carrying one isn't worth keeping or sharing — and an old link should hand over a good one. The dbId is resolved to its stable id and that is navigated to:
#1280218/PathwayBrowser/R-HSA-1280218#9932451/PathwayBrowser/R-HSA-9932451(163 elements)#R-HSA-202733If the lookup fails it falls back to the dbId, which loads — a page on a worse URL beats a link that goes nowhere, and refusing to navigate would turn a working legacy link into a dead one.
Four digits minimum, so an ordinary page anchor can't be taken for a dbId; the shortest in the content is five, and there are no shorter numeric fragments.
It also closes the last gap in the release checklist
RELEASE-TESTING.mdasked a person to check that "a newly added pathway, reaction and complex render" every release — which a test can't hardcode, because what's new changes each time. It doesn't need to: the announcement names them.e2e/release/new-in-this-release.spec.tsreads the newest release note in the repo, opens each link exactly as written, and asserts each lands on a stable id. 21 for v97, all passing.That leaves the checklist at 48 auto, 8 human, 2 missing, 0 gaps.
Not covered
The content still writes dbIds — 13 curated files, authored through the CMS. Rewriting those to stable ids is a separate question and yours to call.
🤖 Generated with Claude Code