Skip to content

Bound per-endpoint DB concurrency and fix a false-empty UI flash on large APIs - #36

Merged
SayantanCode merged 1 commit into
mainfrom
fix/bounded-concurrency-and-loading-state
Jul 26, 2026
Merged

Bound per-endpoint DB concurrency and fix a false-empty UI flash on large APIs#36
SayantanCode merged 1 commit into
mainfrom
fix/bounded-concurrency-and-loading-state

Conversation

@SayantanCode

Copy link
Copy Markdown
Owner

Summary

Found while running vayo scan/vayo export and the docs UI against a real, 600+ endpoint production API (reported directly by a user testing against their own backend):

  • Sequential per-endpoint DB round-trips were slow enough to look hung. vayo scan's route-merge loop and vayo export/vayo diff's per-endpoint override/example/test-script lookups — plus the identical logic in @vayo-hq/server's GET /api/spec/GET /api/diff — ran one DB call at a time in a sequential for...of. Safe, but measured taking minutes at 600+ endpoints against a real remote MongoDB cluster; a user watching vayo scan reasonably assumed it had hung and killed it manually (it hadn't — it does correctly process.exit(0) at the end, it just never got there in a reasonable time).
  • A false "no endpoints" flash in the docs UI. The sidebar and main pane rendered their empty state immediately on load, before the first spec/folders fetch resolved — indistinguishable from a project with genuinely nothing captured. Combined with the above, a real API's slower response made this a visible, several-second false flash.

Changes

  • Added mapWithConcurrency (bounded-concurrency Promise.all, 20 at a time) to @vayo-hq/schema-engine, shared by both cli and server since they duplicate this exact per-endpoint-resolution logic.
  • Switched every sequential/unbounded per-endpoint loop in scan.ts, export.ts, diff.ts, and server/routes/versions.ts to use it.
  • DocsApp now tracks whether the initial fetch is still pending (initialLoadPending) and shows "Loading endpoints…" instead of the empty-state message in FolderTree, the main pane, and FullDocView, until it resolves.

Test plan

  • pnpm build — passes
  • pnpm lint — clean
  • pnpm check:boundaries — clean
  • pnpm test — 653/653 passing (4 new tests for mapWithConcurrency; fixed two existing test files' @vayo-hq/schema-engine mocks that didn't account for the new export)
  • CI green on this PR

…arge APIs

Found while running vayo scan/export and the docs UI against a real,
600+ endpoint production API: the sequential per-endpoint DB round-trips
in scan/export/diff (and the identical logic in @vayo-hq/server's
GET /api/spec and GET /api/diff) took minutes at that scale, easily
mistaken for a hang. Added mapWithConcurrency to @vayo-hq/schema-engine
and switched every one of these loops to it.

Separately, the docs UI rendered "No endpoints yet"/"No endpoints
captured yet" immediately on load, before the first fetch resolved -
indistinguishable from a project with nothing captured, and a real,
visible flash on an API slow enough to hit the issue above. DocsApp now
tracks the initial-load state and shows a loading message instead.
@SayantanCode
SayantanCode merged commit 54d83dd into main Jul 26, 2026
3 checks passed
@SayantanCode
SayantanCode deleted the fix/bounded-concurrency-and-loading-state branch July 26, 2026 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant