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.
Summary
A workspace-wide
cargo testcannot link theperry-ext-http/perry-ext-http-serverlib testbinaries: undefined
js_request_new/js_response_new. The same crates build and test finestandalone (
-p perry-ext-http), which points at cargo feature unification across theworkspace 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:
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:
js_zlib_deflate_raw_sync+panic_unwind, cold object cache onlypanic_fmt/panic_nounwind_fmt/__rust_alloc_error_handler, cold cache onlyjs_request_new/js_response_new, workspace build onlyEach 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 undercrates/*/tests/*.rsrun nightly/tag only, not per-PR — soa 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.