shadcn-sync 的 registry 请求没有超时:连接被黑洞时 pnpm shadcn:check 会一直挂着(46 次串行请求) #4031

Activity

1. os-zhuang

   added

   pm:queue

   on Aug 10, 2026
2. yinlianghui commented on Aug 10, 2026

   

   yinlianghui

   on Aug 10, 2026 – with Claude

   Contributor

   More actions

   Context from #3586 / PR #4174, which bounds the blast radius of this without fixing it.

   That PR adds timeout-minutes: 20 to the shadcn-check job, so a black-holed connection now costs 20 minutes of a runner instead of the 360-minute default. The fetchUrl gap this issue names is exactly why that line was needed and why it was sized the way it was: with no socket timeout in the script, nothing else bounds the hang.

   Two measurements taken while sizing it, in case they are useful here:

   • Run 31374857502 (2026-08-10) completed all 46 serial requests in ~1.7 s (09:30:22.71 to 09:30:24.03), i.e. ~37 ms per request, with Registry: 0 cached, 46 fetched and 0 errors. So the healthy path has enormous headroom — a per-request timeout of even 10 s would be ~270x the observed per-request cost and would never fire in normal operation.
   • All 30 runs in the workflow's API history completed in 19-49 s wall clock, so there is no historical run that a per-request timeout in that range would have disturbed.

   The job timeout is a backstop, not a substitute: it turns a hang into a 20-minute red job rather than into a fast, well-attributed error naming the component that hung, and it does nothing for anyone running pnpm shadcn:check locally. This issue stays the real fix.

   ---

   Generated by Claude Code
3. yinlianghui

   added

   pm:dispatched

   auto-adjudicated

   and removed

   pm:queue

   on Aug 15, 2026
4. yinlianghui

   self-assigned this

   on Aug 15, 2026
5. yinlianghui commented on Aug 15, 2026

   

   yinlianghui

   on Aug 15, 2026 – with Claude

   Contributor

   More actions

   Claiming — PM dispatch, with a delegated adjudication (veto window open). Session: session_01RnQd8iMMUwXQEV1crFmQiQ (objectui whole-repo PM seat). Branch: claude/issue-4031-shadcn-sync-timeout.

   Adjudicated (within delegation gates — build-script tooling, no contract surface): per-request timeout 10s, no retry, fail fast with an error that names the URL that hung. Basis: the 2026-08-10 measurements on this card — healthy path is ~37ms/request (10s ≈ 270× headroom), all 30 historical runs complete in 19–49s wall clock, so the timeout never fires in normal operation; a black-holed connection does not resolve in seconds, so a retry only doubles the worst-case hang budget while the existing error path already degrades gracefully (--check marks the error, --update refuses to write). The 20-minute job backstop from PR #4174 stays as-is — this is the real fix it was standing in for. Maintainer may veto/adjust the value on this card; the dispatch proceeds meanwhile.

   Scope: scripts/shadcn-sync.js fetchUrl (req.setTimeout(10_000, …destroy…) shape), all 46 serial requests covered; error text names the component/URL; verify both --check and --update degrade exactly as the card describes. PR will be Fixes #4031.

   ---

   Generated by Claude Code
6. yinlianghui commented on Aug 15, 2026

   

   yinlianghui

   on Aug 15, 2026 – with Claude

   Contributor

   More actions

   <!-- os-dev-report -->

   {
     "issue": 4031,
     "status": "done",
     "branch": "claude/issue-4031-shadcn-sync-timeout",
     "pr": "https://github.com/objectstack-ai/objectui/pull/4715",
     "premise_still_valid": true,
     "summary": "Added a 10s per-request timeout (no retry, per the delegated adjudication on the issue thread) to fetchUrl() in scripts/shadcn-sync.js via req.setTimeout(timeoutMs, () => req.destroy(new Error(...))); the error names the URL that hung and reuses the existing req.on('error', reject) path, so --check/--update degrade exactly as before. timeoutMs threads through fetchRegistry too, defaulting to the same 10s. Mechanism assumptions confirmed: (1) fetchUrl used bare https.get with only error/end listeners, no timeout at all -- true, read at scripts/shadcn-sync.js:139 pre-fix. (2) --check runs 46 serial requests where non-2xx/non-JSON already reject with a reason (PR objectui#3496), so a silent hang was the only remaining failure mode -- true. (3) req.setTimeout + destroy(error) covers both a dropped-SYN and a connected-but-silent peer, since Node arms the idle timer as soon as a socket is assigned to the request, before the handshake resolves -- confirmed: a deterministic get-double is committed as the automated test, and a REAL raw-net hung server was verified manually (standalone Node script, inside a worker_threads Worker, and end-to-end via the real CLI against a temporarily-patched packages/components/shadcn-components.json entry, reverted before commit). The identical real-socket scenario proved flaky specifically inside Vitest's threads pool while this shared container had a sibling agent's heavy pnpm build pegging multiple cores (silent for a 20s it() bound, not slow -- reproduced with -t isolating the one test and --maxWorkers=1), which is a Vitest/contention interaction, not a defect in fetchUrl -- so that path is committed as the double rather than a real-socket vitest test, per this repo's own flaky-test discipline against widening budgets to paper over a race. Full reasoning and the manual verification transcript are in the PR body.",
     "tests": "pnpm exec vitest run scripts/__tests__/shadcn-sync-fetch-cache.test.ts --maxWorkers=2 -> 26/26 passed, 766ms, at HEAD 995a6fdad. pnpm run type-check:scripts (tsc -p tsconfig.scripts.json) -> 0 errors. node scripts/check-control-bytes.mjs -> OK, 4238 tracked files scanned. pnpm run lint:root -> 0 errors, 22 pre-existing warnings, none in changed files. node scripts/check-changeset-presence.mjs -> no changeset owed (scripts/ is not in .changeset/config.json's fixed release group); objectui has no skip-changeset label so none applied -- PR was auto-labeled 'tests' by existing repo automation, read back after creation via pull_request_read. Healthy-path regression check: pnpm shadcn:check against the live (egress-blocked) registry -> all 46 requests fail via immediate HTTP 403, total wall 0.481s, zero timeouts triggered. Manual hang simulation (adjudication route item 2): temporarily pointed the accordion manifest entry at a local raw-net server that accepts a connection and never responds; node scripts/shadcn-sync.js --check -> accordion times out at exactly 10000ms naming the URL (other 45 components unaffected via their normal 403 path), exit 0; node scripts/shadcn-sync.js --update accordion -> same 10000ms timeout naming the URL, md5sum of packages/components/src/ui/accordion.tsx unchanged before/after, git status clean (no write) -- --check/--update both degrade exactly per the existing error path. Manifest reverted via git checkout before the commit; git status/diff --stat confirm only the two intended files changed. Changed files (2): scripts/shadcn-sync.js, scripts/__tests__/shadcn-sync-fetch-cache.test.ts. PR #4715, head sha 995a6fdadb0a6d8e2a2c5a664ce003d9c6bb6a43 (short 995a6fdad) -- gate union above and the PR body both quote this same sha, run after the final commit.",
     "open_questions": [],
     "out_of_scope_findings": []
   }

   ---

   Generated by Claude Code
7. yinlianghui

   closed this as completedin #4715on Aug 15, 2026
8. yinlianghui

   removed

   pm:dispatched

   on Aug 15, 2026