Repository navigation
Remove unused bun-tracestrings dependency - #25425
dylan-conway wants to merge 2 commits into
Conversation
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Updated 6:51 PM PT - Dec 8th, 2025
❌ @dylan-conway, your commit 2b1f955 has 5 failures in
🧪 To try this PR locally: bunx bun-pr 25425That installs a local version of the PR into your bun-25425 --bun |
WalkthroughRemoved the Changes
Suggested reviewers
Pre-merge checks✅ Passed checks (2 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📥 CommitsReviewing files that changed from the base of the PR and between f25ea59 and bc2cd1f3589131a104d965b0457fb11e16758298. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
Comment |
🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
bc2cd1f to
2b1f955
Compare
|
|
||
| "buffer-equal-constant-time": ["buffer-equal-constant-time@1.0.1", "", {}, "sha512-zRpUiDwd/xk6ADqPMATG8vc9VPrkck7T07OIx0gnjmJAnHnTVXNQG3vfvWNuiZIkwu9KrKdA1iJKfsfTVxE6NA=="], | ||
|
|
||
| "bun-tracestrings": ["bun-tracestrings@github:oven-sh/bun.report#912ca63", { "dependencies": { "@octokit/webhooks-methods": "^5.1.0", "@sentry/types": "^7.112.2", "@types/bun": "^1.2.6", "html-minifier": "^4.0.0", "lightningcss": "^1.24.1", "marked": "^12.0.1", "octokit": "^3.2.0", "prettier": "^3.2.5", "typescript": "^5.0.0" }, "bin": { "ci-remap-server": "./bin/ci-remap-server.ts" } }, "oven-sh-bun.report-912ca63"], |
There was a problem hiding this comment.
could this have been here so you can run bunx ci-remap-server ... type thing? idk if anyone used it tho
There was a problem hiding this comment.
ah you're right. I forgot the binary from the package might be the only thing used!
There was a problem hiding this comment.
CI stack traces rely on ci-remap-server:
Line 545 in 2028e21
…ls never download from GitHub (#39446) ### Problem - The "Lint JavaScript" (lint.yml) and "Format" (format.yml) checks go red on PRs that did not touch anything they check. Their `bun install` step fails with: ``` error: failed to download bun-tracestrings@github:oven-sh/bun.report#912ca63: HTTP 5xx Failed to install 1 package ``` Seen on #29642 at 5309742 (a C++ comment change), both attempts of runs 32040959983 and 32040960113, while other PRs' Lint runs flapped red/green in the same minutes. - Cause: `package.json:13` pins `bun-tracestrings` as a `github:` dependency, so every root `bun install` downloads a tarball from GitHub. That install runs on a fresh runner (no cache) in lint.yml, format.yml, rust-lints.yml (4 jobs), bun-types.yml and packages-ci.yml, and in every build (`scripts/build/codegen.ts` `bun_install`). bun retries a tarball 5 times back to back, which does not cover an outage of a few minutes. - The only user of the package is `scripts/runner.node.mjs`, which runs its `ci-remap-server` bin on Buildkite test shards (`runner.node.mjs:803` on main). Nothing in lint, format, types, rust-lints or the build uses it. Removing it outright was tried in #25425 and closed for that reason. ### Fix - Move the dependency to a new `scripts/ci-remap-server/package.json` (+ `bun.lock`) and drop it from the root `package.json` / `bun.lock` (a pure removal: 94 lockfile entries, the package and its transitive closure; the lockfile stays `lockfileVersion: 1`). - `runner.node.mjs` installs that directory right before starting the server, through the same `spawnBunInstall` as root and test/ so it uses the agent's baked install cache, and runs the bin from there. The install is best-effort like the server start already is: on failure it warns and the tests run without crash remapping instead of failing the shard. - `bootstrap.sh` warms the new directory into the image's install cache next to root and test/. No image version bump needed: the new lockfile carries over the exact resolutions the root lockfile had (checked entry by entry), so the caches baked from the old root lockfile already contain everything except `@types/bun@1.3.14` and `bun-types@1.3.14`, which resolved to the workspace packages before and now come from npm. - New source lint `test/internal/source-lints/lockfile-registry-only.test.ts`: the root and test/ lockfiles (the two that every PR's checks and every shard install) may not contain `github:`, `git+` or tarball-URL resolutions. `source-lints.yml` now also triggers on `bun.lock` / `test/bun.lock`. - Why this is the right layer: the failing jobs had no use for the package, and a retry or cache in lint.yml/format.yml would still leave GitHub on the install path of rust-lints, bun-types, the build and every dev's `bun install`, and would still fail during a multi-minute blip. After this, root installs only talk to the npm registry; the one job that needs GitHub gets it from a baked cache and degrades gracefully when it is unavailable. - Verified: - `test/internal/source-lints/lockfile-registry-only.test.ts`: fails on main's `bun.lock` (`bun-tracestrings -> bun-tracestrings@github:oven-sh/bun.report#912ca63`), passes here, under `bun bd test`, the system bun and bun 1.3.14 (the version the workflows pin). Whole `test/internal/source-lints/` passes. - Root `bun install --frozen-lockfile` (lint.yml's command) with bun 1.3.14 and the debug build: no changes. Fresh checkout with GitHub unreachable (`GITHUB_API_URL=http://127.0.0.1:1`, empty cache): main fails with `failed to download bun-tracestrings@github:... ConnectionRefused`, this branch installs. - `bun install --frozen-lockfile` in `scripts/ci-remap-server` with bun 1.3.14, canary and the debug build: no changes; `bun run --silent ci-remap-server` from that directory prints a port and serves `/traces`. - This PR's own Buildkite build (#100049): every non-Windows shard logs `scripts/ci-remap-server/package.json` / `86 packages installed` in 0.4 to 1s (the baked cache, as predicted; the root install went from 102 packages to 21), followed by `crash reports parsed on port ...`. The server came up on 17 of 40 debian+ubuntu x64 shards against 14 of 40 on main's build #100080: the remaining shards hit the runner's pre-existing 5s startup timeout (`ci-remap server did not start: timeout`), which this PR does not change and is worth a follow-up of its own. - Locally, `CI=true node scripts/runner.node.mjs ...` with a cold cache got a 429 from codeload.github.com for the tarball; the runner warned `ci-remap server not installed (...), crash reports will not be remapped`, ran the test and exited 0. Same with the directory removed (`spawn error`). - `bun lint`, prettier `--check` on the touched files, `sh -n scripts/bootstrap.sh`, `bun bd` reconfigure after the root package.json change. - Overlaps with #38981 on neighbouring lines of the same block in `runner.node.mjs` (it changes how the server is killed, this changes where it is installed and started); either rebases trivially onto the other. ### Background - `bun-tracestrings` is the npm name of github.com/oven-sh/bun.report, the service that turns the trace strings in bun's crash reports back into stack traces. Its `ci-remap-server` bin is a local copy of that: `runner.node.mjs` starts it, points every spawned bun at it via `BUN_CRASH_REPORT_URL`, and prints the remapped traces of any test that crashed. It is purely diagnostic output; tests still fail on their exit code without it. - A `github:` dependency has no registry tarball: bun downloads it from GitHub on install (and caches it under the same name@resolution key as registry packages). - `bootstrap.sh` builds the CI agent images. It clones the repo and runs `bun install` in root and test/ with `BUN_INSTALL_CACHE_DIR` set, so test shards install from disk; a package only downloads when its resolution is not in the baked cache. The `# Version:` header is only bumped when the image itself must change, which this does not require. - `test/internal/source-lints/` holds repo-invariant tests that run on a bare checkout in source-lints.yml (no `bun install`), which is why the lint lives there and why that workflow's path filter had to learn about the lockfiles.
Summary
bun-tracestringsdevDependency from package.jsonTest plan
🤖 Generated with Claude Code