[Mikola Lysenko (mikolalysenko)]

Problem

The coverage leg (the gating Linux test run behind ci-ok) builds an instrumented socket-patch, and the self-update e2e suites serve that same binary to the updater as a fake release asset. The updater refuses any binary over 256 MiB (MAX_BINARY_BYTES, crates/socket-patch-core/src/update/download.rs). Main's instrumented binary is close to that cap, and a large feature is enough to cross it:

• feat/bazel-support (about 96k lines of new src), run 43482044084: both coverage shards fail with 8 self-update tests (self_update_failures_e2e, self_update_channels_e2e, self_update_telemetry_e2e, update_json_contracts), with Downloaded binary failed verification: socket-patch exceeds the 268435456-byte cap / verify_failed where permission_denied was expected.
• On main the same tests pass in CI today (merge_group run 43449209163), but a local -C instrument-coverage build of main's socket-patch is already 274,450,464 bytes, over the cap. With this setting, those tests failed locally on main too (see Proof).

If that branch or any comparable growth lands, every merge-queue entry fails coverage and the queue blocks.

Root cause

[profile.dev] debug = "line-tables-only". In the instrumented binary, about 107 MB is .debug_* (.debug_str 44 MB, .debug_line 29 MB, .debug_info 22 MB, .debug_ranges 12 MB). The fixture serves this test build artifact, not a release-sized binary.

Fix

Set CARGO_PROFILE_DEV_DEBUG: '0' on the coverage job only. This is the same setting e2e-build already uses. llvm-cov maps coverage from the __llvm_cov* sections, not DWARF. A panic's file:line comes from #[track_caller], so neither the LCOV nor the failure annotations change, and CI doesn't set RUST_BACKTRACE. The production cap stays as it is.

Proof

Local, rustc 1.93.1, RUSTFLAGS="-C instrument-coverage --cfg=coverage --cfg=trybuild_no_target", cargo test -p socket-patch-cli --test self_update_failures_e2e on main:

debug	instrumented socket-patch	result
line-tables-only (today)	274,450,464 B	FAILED: 16 passed, 2 failed (explicit_pin_downgrades_without_force, concurrent_update_lock_held)
0 (this PR)	163,112,208 B	ok: 18 passed

The CI change only takes effect on a new head commit, so this PR's own coverage shards check it.

• No tests are removed or moved. Required-check names and ci-ok don't change.
• actionlint and zizmor aren't installed in this session. The YAML parses, and the scripts/tests unittest suite passes (411 tests).
• Side effect: the coverage rust-cache key changes, so the first run on main rebuilds dependencies once.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

PR Summary

Low Risk
CI-only environment tweak for the coverage job with no production binary or updater logic changes; intended effect is preventing false self-update e2e failures on large builds.

Overview
Sets CARGO_PROFILE_DEV_DEBUG: '0' on the coverage job so the instrumented socket-patch binary stays under the self-update 256 MiB cap exercised by the self-update e2e suites (the same setting e2e-build already uses).

With default dev line-tables-only debug, DWARF bloated the coverage artifact (~274 MB locally) and large branches could push CI over the limit and fail those tests. Disabling debug info trims the binary (~163 MB locally) while llvm-cov still maps coverage from instrumentation sections and panic locations stay unchanged for LCOV and failure annotations.

A YAML comment documents the rationale; the first post-merge coverage run will use a new rust-cache key and may rebuild dependencies once.

^{Reviewed by Cursor Bugbot for commit 0774706. Configure here.}

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 0774706. Configure here.}

[Mikola Lysenko (mikolalysenko)]

coverage (1) failed in crawlers::composer_crawler::tests::equivalence::randomized_vendor_trees_match_the_async_oracle (socket-patch-core lib unit test). This PR doesn't cause it: the PR only drops DWARF, which can't change crawler behaviour, and the test is a race on main since #2064. Its #[serial] test holds COMPOSER_VENDOR_DIR=held in an EnvGuard while the non-serial oracle test reads the same var. Filed as #2072 with the evidence. I'll re-run the failed shard once after the run finishes.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[agent] PR shepherd: review brief for the approver

What it does. The coverage CI job (behind ci-ok) now builds without DWARF (CARGO_PROFILE_DEV_DEBUG: '0'). The self-update e2e tests serve that instrumented binary as a fake release asset. With debug line tables it is about 274 MB locally, over the updater's 256 MiB cap, and it already broke feat/bazel-support. This keeps the merge queue from blocking once main grows.

Risk: low. It changes one environment variable on one CI job, and no product code. e2e-build already uses the same setting. llvm-cov reads the __llvm_cov* sections, not DWARF, so the coverage data doesn't change. The one cost: the coverage rust-cache key changes, so the first run on main rebuilds dependencies once.

Look here

• ci.yml:704: the setting and the comment explaining it

Verified

• I read the diff and the description, and they match. CHANGELOG.md is untouched, and so is the production cap (MAX_BINARY_BYTES).
• The job's profile.dev has no per-package debug override that would undo it, and cargo llvm-cov show-env sets only RUSTFLAGS, so the variable takes effect.
• CI is green on 0774706, including both coverage shards, ci-ok and clippy. One shard was re-run once after an unrelated flake tracked in Flake: composer oracle test races the COMPOSER_VENDOR_DIR EnvGuard added in #2064 #2072. Bugbot left no threads.

Changes I made: none.

Open questions: none.

---

Generated by Claude Code