Conformance: jco targets blocked on upstream jco defects in composed p3 stream/future paths

[lann]

The conformance suite's jco legs (Node, browser) cannot run yet: transpiling the composed artifact (suite ⊕ polymorph:tls component) trips two defects in jco's p3 support, verified against the latest lann/jco fork build (jco-transpile-0.6.2-fa6990d, the pin the websocket sibling uses), Node 24.18, --experimental-wasm-jspi.

1. TDZ emission-order defect (shallow). With instantiation: "async", the generated module references the future.transfer trampoline inside _initGenerator before its const declaration is emitted:

ReferenceError: Cannot access 'trampoline92' before initialization

The matching stream.transfer trampoline (trampoline91 = streamTransfer) is emitted before its use; the future one lands after. Hoisting the declaration by hand gets past instantiation.

2. Missing current-task context in streamTransfer (deep). With 1 patched, the run proceeds — sync and async calls across the composed boundary work (identity.ed25519 rejection and the async identity.delegated failure both complete) — until the first p3 stream is passed across the composed wasm↔wasm boundary (connector.send), called from a detached-task continuation inside the component:

Error: missing global current task globalTaskMeta
    at streamTransfer (...)
    at ... connector.send
    at ... wit_bindgen::rt::async_support::FutureState::callback

The scheduler does not establish the current-task global when an async-lifted export's continuation (wit-bindgen 0.60 FutureState::callback) invokes a stream intrinsic. This is the composed-shape variant the websocket sibling's suite never exercises: there the p3 streams cross wasm↔JS (the suite is transpiled un-composed, the SUT is a JS host module), while here two components are fused by wac plug first. Same defect class as the scheduler issue blocking component-iroh's jco endpoint leg (lann/jco#11).

Repro: just build-wasm, wac plug --plug target/wasm32-wasip2/debug/polymorph_tls_component.wasm target/wasm32-wasip2/debug/tls_loopback.wasm -o tls-composed.wasm (any rev before the conformance cutover; after it, compose the suite per conformance/driver-ct/justfile), transpile with the fork at instantiation: "async", bind the preview2-shim wasi 0.2 imports, and call the exported async run. Under wasmtime 47 (-W component-model-async=y) the same artifact passes.

What unblocks: both defects fixed upstream (the first is mechanical; the second is scheduler work). When they land, add jco-node (and a browser leg behind the CI/CONFORMANCE_BROWSER=1 predicate, optional = true) to conformance/driver-ct/targets.toml and a driver mirroring the websocket sibling's conformance/driver-ct/jco/ (upstream @polymorph/component-test-js harness core, fresh instance per case, results JSONL into the same aggregate).

[lann]

Filed upstream, with a corrected diagnosis for the second defect: lann/jco#34 (the TDZ emission-order bug) and lann/jco#35 (the stream-transfer failure).

Two corrections to this issue's original text, from a deeper JCO_DEBUG=1 trace:

1. "Same defect class as Execution-slot queue serializes task lifetimes: a long-lived task deadlocks every later export call on the instance lann/jco#11" is superseded. The tested build (all-fixes @ fa6990d) already contains the JSPI current-task register fix (fix(bindgen): keep the current-task register correct across JSPI suspensions lann/jco#29); Upstream the QUIC packet protection and a provider-agnostic quinn-rustls feature #11's execution-slot fix is not on all-fixes (fix(bindgen): four P3 task-concurrency fixes toward #11 lann/jco#27 was closed unmerged, only its register commit was extracted), but Upstream the QUIC packet protection and a provider-agnostic quinn-rustls feature #11 is unrelated to what we hit. The actual mechanism: for a sync-lifted fused call returning a stream, the callee's task teardown (_clearCurrentTask) nulls the per-component current-task register before the fused adapter transfers the returned stream end, and streamTransfer derives its task context from the stream-owning (callee) component's register. Argument-position transfers in the same call succeed; return-position transfers cannot.

2. Async guest→guest calls work on the tested build (the original text implied the failure sat in async continuation delivery). The failing ingredient is specifically return-position stream/future results on sync-lifted fused calls — which the send/receive transform-pair surface uses pervasively, so the conformance jco legs remain blocked until -I async: future.transfer trampoline const is emitted after the init generator that references it (TDZ ReferenceError at instantiation) lann/jco#34 + Add the jco-browser conformance targets on the upstream page driver #35 land.

Both defects reproduce identically on upstream @bytecodealliance/jco-transpile 0.6.3, so fixes may need to travel further than the fork.

[lann]

Status update: defect 1 (lann/jco#34, the TDZ emission-order bug) is fixed upstream on the fork's all-fixes branch (head eaad4c3, merging fix/future-transfer-trampoline-order — with a composed cross-component future-transfer regression test). Verified against this repo's original repro with a locally packed build of that head: instantiation proceeds unpatched.

Defect 2 (lann/jco#35) reproduces unchanged on the same build — the return-position streamTransfer after callee teardown — so the jco targets remain blocked on #35 alone.

Consumability: no release tarball exists past jco-transpile-0.6.2-fa6990d yet; the sibling convention pins release tarballs, so adopting the #34 fix (and eventually the #35 fix) waits on the next fork release. When both land in a release, the leg unblocks: add jco-node/jco-browser rows to conformance/driver-ct/targets.toml and a driver on the upstream harness + ./imports glue per the webcrypto/websocket shape.

[lann]

Ladder update, verified against all-fixes @ 89d6289 (locally packed build; still no release tarball past fa6990d):

• -I async: future.transfer trampoline const is emitted after the init generator that references it (TDZ ReferenceError at instantiation) lann/jco#34 (TDZ): fixed — instantiates unpatched.
• Fused sync call returning a stream: callee task teardown clears CURRENT_TASK_META before the return-position streamTransfer ('missing global current task') lann/jco#35 (return-position transfer): fixed — the full send/receive transform-pair wiring completes, stream and future transfers included.
• New blocker: Fused cross-component stream I/O: write completion/readiness never delivered to the peer's parked reads (both components poll hasPendingEvent forever) lann/jco#40 — the first fused cross-component stream write (the ClientHello flight) is never delivered to the peer's parked reads; both components spin in hasPendingEvent forever (silent hang, timeout exit). This is the scheduler-delivery cluster (Cross-implementation interop and the real-transport TLS demo #13-adjacent, possibly compounded by Upstream the QUIC packet protection and a provider-agnostic quinn-rustls feature #11's execution-slot serialization) — the same territory blocking component-iroh's jco endpoint leg.

The jco targets stay blocked on #40 (and on a fork release existing once it's fixed). The transfer-layer progress is real: everything up to actual handshake byte flow now works under jco.

[lann]

Ladder update: my round-trip pairing hypothesis was wrong — building the minimal reproducer (lann/jco#43) showed both transfers succeed, and the hang reduces to lann/jco#11 (execution-slot serialization: one live task per component instance). The TLS component needs two by construction — connect and accept run concurrently on one instance, each side's pump feeding the other's handshake — so the jco leg is blocked on #11's relaxation (which upstream has parked pending lann/jco#30/#31). Current ladder: #34 fixed, #35 fixed, #40 → #11 (+ #30/#31 beneath it), no fork release cut yet. The reproducer's skip-test in lann/jco#43 is the upstream flip-gate; when it flips, re-run this artifact for any residual layers before wiring the conformance targets.

[lann]

The jco legs are unblocked: on the lann/jco all-fixes build all-fixes-dbad4d7 (release tarball bytecodealliance-jco-transpile-0.6.3-gdbad4d7.tgz), a jco Node driver over the composed targets scores composed 7/7 and composed-delegated 7/7 — full parity with the wasmtime ct-runner legs.

The path from this issue's two defects to green, all on lann/jco:

• Bump component-test to eabd159; slim the jco driver onto the upstream loop #34 (the TDZ, defect 1 here) — fixed in fix(bindgen): emit future.transfer trampoline before instantiation code lann/jco#36.
• Add the jco-browser conformance targets on the upstream page driver #35 (the streamTransfer current-task lookup, defect 2 here) — fixed in fix(bindgen): drop current-task lookup from stream.transfer lann/jco#38; the issue's "same defect class as Upstream the QUIC packet protection and a provider-agnostic quinn-rustls feature #11" hunch was right in spirit: behind it sat Fused cross-component stream I/O: write completion/readiness never delivered to the peer's parked reads (both components poll hasPendingEvent forever) lann/jco#40 (execution-slot serialization + a resumption-cascade register race, fixed in fix(bindgen): allow concurrent task lifetimes within a component instance lann/jco#42, which also resolves Upstream the QUIC packet protection and a provider-agnostic quinn-rustls feature #11's headline case).
• futureTransfer intrinsic is an unimplemented stub: composed future handoff delivers rep 0 to the receiving component ('invalid resource rep during get') lann/jco#37 — futureTransfer was an unimplemented stub (rep 0 to the receiving component); this is what handshake/alpn-sni, data/echo, and shutdown/close-notify tripped once instantiation worked. Fixed in fix(bindgen): implement future.transfer lann/jco#44.
• SyncStartCall is an unimplemented stub: async-lowered calls to sync-lifted fused callees throw 'synchronous start call not implemented' (then wedge to case timeout) lann/jco#45 — SyncStartCall was an unimplemented stub; delegated/handshake's tls→signer blocking call (sync-lowered import of the async-lifted signer) hit it, first as a 60 s wedge, then — once implemented — as "no usable signature schemes" (the sync lowering's spilled-result return pointer wasn't extracted, so the scheme list was written to address ~0). Both fixed in fix(bindgen): implement sync-start-call for sync-lowered calls to async-lifted callees lann/jco#46.

Driver notes for the jco-node target this issue sketches: mirroring the websocket sibling's conformance/driver-ct/jco/ works with three deltas — no SUT import object (the SUT is composed in; sut: {}), wasiVersions: ["0.2.6"] to match the suite's import spellings, and per-flavor --missing (["delegated-signer"] for suite-plain). Transpile the composed artifacts (target/conformance/suite-{plain,delegated}.wasm) with component-test-jco-transpile ... -I async. The all-fixes releases are now built automatically on every merge to that branch (https://github.com/lann/jco/releases/tag/all-fixes-<sha7>), so the pin can follow the same pattern as the websocket sibling's. Happy to PR the driver + targets.toml entries if useful — the working files are exactly the sibling's shape.