Repository navigation
build: workspace cargo test cannot link perry-ext-http / perry-ext-http-server lib tests (undefined js_request_new/js_response_new; standalone builds fine) #6973
Description
Summary
A workspace-wide cargo test cannot link the perry-ext-http / perry-ext-http-server lib test
binaries: undefined js_request_new / js_response_new. The same crates build and test fine
standalone (-p perry-ext-http), which points at cargo feature unification across the
workspace changing which runtime surface gets linked into the test binary.
Provenance — read before acting
Observed during the #6951 sweep (PR #6972) and verified identical on origin/main, i.e.
pre-existing and unrelated to that change. I have not independently re-verified it myself; the
first step for whoever picks this up is to reproduce both arms:
cargo test -p perry-ext-http --no-run # expected: links
cargo test --workspace --no-run # expected: undefined js_request_new / js_response_new
If it does not reproduce, close this — it may have been an artifact of that agent's local tree.
Why it is worth tracking rather than shrugging at
This is the third ext provider in a fortnight to fail at link time from a packaging/feature
mismatch rather than a code defect:
| provider | issue | symptom |
|---|---|---|
| ext-zlib | #6847 | undefined js_zlib_deflate_raw_sync + panic_unwind, cold object cache only |
| ext-events | #6966 | undefined panic_fmt / panic_nounwind_fmt / __rust_alloc_error_handler, cold cache only |
| ext-http / ext-http-server | this | undefined js_request_new / js_response_new, workspace build only |
Each was filed separately and each has a different proximate trigger, but the shape repeats: an ext
provider archive gets paired with a runtime built under a different feature set than the one its
symbols were compiled against. It is worth someone looking at whether these three share a root cause
in how ext provider archives select/pin their runtime features, rather than fixing three symptoms.
Why CI does not catch it
Per CLAUDE.md, integration suites under crates/*/tests/*.rs run nightly/tag only, not per-PR — so
a workspace-only link break can land green and sit red for days. That is the same CI-invisibility
that #6936 and (until recently) #6947 had.
Activity
proggeramlug commentedon Aug 5, 2026
crates/perry-ext-http-serverno longer exists — merged intoperry-ext-httpby #6826, one day after this was filed. Zero references remain inCargo.toml. The cited undefined symbolsjs_request_new/js_response_neware defined inperry-ext-fetch, notperry-ext-http.Per the issue's own text: "If it does not reproduce, close this."