fix(viewer): the routes list's limit counts routes, not one route's calls

The routing manifest has a row per (route, symbol it reaches), and the
routes list behind Entry points and the Steps picker folds those rows to
one per route. To have rows to fold, it fetched limit * 4 + 1 of them,
so an inline handler, which has a row per call in its body, could use
up the window by itself, and the routes after it were never fetched. On
an Express app with one 24-call inline handler before two routes,
limit=3 listed only GET /dense.

getRoutingManifest takes a perRoute flag that applies its limit to
routes, in the same file and line order, and returns every row of those
routes. Without the flag the query and its result are unchanged.

Added on top of the contributor's change: the window is still
over-fetched, four routes per route shown, because some routes are
dropped only after their rows come back (a test or generated handler,
an inline route written in a test). A window of exactly limit + 1
routes could hold only those. On hono, whose routes are nearly all
registered in test files, Entry points then listed 0 routes instead of
main's 28, and the routes list 21 instead of 32. With the over-fetch,
every route main lists is still listed at each limit tried (3, 12, 60,
200 and 300), and hono's Entry points list 32. truncated also keeps
main's check that the window came back full.

Validation: the new limit=3 test fails on main (only GET /dense) and
passes here. A project whose test-file routes sort first fails with the
PR as first written (it reads as unrouted) and passes here and on main.
Routes listed on Wiki.js (132 routes) and realworld-express are
identical to main, and on hono they differ only by the additions above.
The ui suites and the other route consumers: 34 files, 723 passed, 0
failed, 3 skipped (environment-gated). The changelog line is in
docs/viewer-launch-changelog.md, since the viewer is not released yet.

Original PR #2370 by @danusha2345.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
danusha2345
2026-10-23 16:56:54 +00:00
committed by Colby Mchenry
co-authored by Claude Opus 5.5
parent 2def0a6d6d
commit 33dc2ae72b
5 changed files with 104 additions and 15 deletions
+2
View File
@@ -127,6 +127,8 @@ These describe `codegraph ui` and its screens. They were taken out of `## [Unrel
- **Routes served by a component are listed.** Entry points and the Steps picker listed a route only when a function, method or class served it. A Vue Router, Nuxt, Svelte or Astro screen is served by a component, so those apps' routes weren't listed at all. They are now, each with the component that serves it.
- **One busy inline handler no longer hides the other routes.** Entry points and the Steps picker filled their list by the symbols each route reaches rather than by routes, so an inline handler with dozens of calls could use up the list by itself, and the routes after it went unlisted. They now count routes. Thanks @danusha2345. (#2370)
- **Where the app goes after login is a fork, not two always-es.** A navigation whose destination comes back from a helper — `router.replace(await resolvePostLoginRoute())` over `return (await hasSeenWelcome(…)) ? '/home/' : '/welcome/'` — drew both screens with no condition, reading as if the welcome screen always shows. The two arms share a line, and only a column can tell them apart; each synthesized edge now carries its literal's own position, so the guard reader says which arm it is: `WHEN await hasSeenWelcome(…)` → home, and its negation → welcome. And the scan starts at the helper's body, so a literal-union return type — `Promise<'/welcome/' | '/home/'>`, whose routes are string literals too, written first — no longer stands in for the navigation itself. Re-index after upgrading to pick the positions up.
- **A screen that talks to native code keeps its own navigations.** In a React Native or Expo app, a `router.push` written inside a listener for a native event was credited to whichever screen had *started* that round trip, not to the screen the push is written on. In one app that moved seven transitions off the capture screen and onto the review screen it opens — leaving the review screen looking as though nothing in the app could reach it, stranded in the "no transition reaches this" band at the bottom of the Screens tab, and printing Swift conditions like `Thread.isMainThread` on a JavaScript navigation. A navigation now belongs to the screen whose file it is written in; an event arriving from native code, from an HTTP call or off a queue is no longer read backwards as if it were a caller.