Repository navigation
Estate-wide re-validation of the #199/#205 closure ABI (was static-only until #225 PR2 ran it in a real wasm engine) #235
Description
Problem
#225 PR2 surfaced that the #199 closure ABI / #205 Thenable path had never been executed in a real WebAssembly engine anywhere in the estate. PR1's skeleton was pure pass-through (no closure dispatch); PR2's continuation is the first true end-to-end exercise, and it immediately surfaced two latent defects that static verification had never caught:
- the module never exported
__indirect_function_table(host dispatch impossible); closure_codeusedLocalTeewhere the surrounding code assumesLocalSet, leaving a 2-value stack imbalance (invalid wasm).
Both are fixed in PR #233. But the implication is estate-wide: every downstream consumer that "dogfooded" the #199/#205 surface (e.g. standards#123 rsr-certifier extension, idaptik, boj-server bridges) was static-only — compiled, never run in a wasm host. Their runtime correctness is unverified.
Proposed work
- A minimal
tests/codegenregression that exercises the Deno source-to-source host→guest callback ABI (blocks withProgress/registerCommand/onDidSave) #199 closure dispatch independent of the async transform (a plain captured-closure call through__indirect_function_table), so the shared path is protected for all closure users. - An audit pass: enumerate estate consumers of the Deno source-to-source host→guest callback ABI (blocks withProgress/registerCommand/onDidSave) #199/Wasm-path thenable-resolution: guest consuming a host Thenable result (blocks #103 pilot data path) #205 surface and add a real wasm-host smoke per consumer (or document why static is acceptable there).
Activity
docs(http): #225 PR4 — joint-close #160 + #225 (ADR-013 delivery comp…
docs(http): #225 PR4 — joint-close #160 + #225 (ADR-013 delivery comp…
test(codegen): #235 — engine-validate the #199 closure ABI independen…
hyperpolymath commentedon May 19, 2026
Deliverable (1) shipped (PR #279):
tests/codegen/closure_indirect_dispatch.{affine,mjs}— the #199[fnId@0,envPtr@4]closure ABI is now engine-validated via the exported__indirect_function_tablewith no async/CPS transform involved (imports onlyenv.invokeCallback, nothenableThen). This is the negative-control thehttp_cps_*tests cannot isolate; it protects the shared closure path for every consumer independent of #205. Full wasm harness +dune test --force290 green.Deliverable (2) — estate-consumer audit:
satellites/rsr-certifier/extensions/vscode/src/extension.affine)httpPostJson/thenableThen/thenableResultJson/jsonField; ships its ownwrapHandlerclone (src/affine-vscode-adapter.cjs); zero wasm testsvscode-extension/src/extension.affine)registerCommandclosures only, no #205.tsgenericvscoderegisterCommand— not the AffineScript wasm ABI.affineconsumer (boj-server is the HTTP peer ofhttpPostJson)Remaining tracked item: a runtime smoke for rsr-certifier in the standards repo (cross-repo; the ABI it depends on is now upstream-guaranteed by (1), so this is hardening, not a correctness gap). Leaving #235 open for that.
feat(tw-verify): #10 — enforce L13 module-isolation on emitted wasm (…
hyperpolymath commentedon May 30, 2026
Status refresh (2026-05-30):
The original "surfaced by #225 PR2 → static-only until real-wasm-engine validation" framing is partly resolved: fix PR #233 merged 2026-05-19 with real-wasm-engine exercise of the #199/#205 closure ABI.
Remaining work on this issue:
.affinefixture across the estate, not just the one in stdlib Http: typed-wasm target (convergence ABI; shared with Ephapax) #225).Title could be re-scoped to
Estate audit + regression test for #199/#205 closure ABI (post-#233)if that's clearer.hyperpolymath commentedon Sep 19, 2026
Re-measured the estate-wide half today (2026-09-19) — the language-side exercise is in place; the consumer side has no evidence, so this issue is currently the only tracker for it.
The thread's 2026-05-30 refresh records that #233 merged with real-wasm-engine exercise of the #199/#205 closure ABI, leaving "estate-wide re-validation" as the remaining work. Where that stands now:
affinescripttests/codegen/closure_indirect_dispatch.affineandlib/codegen.mltyped-wasmspec/async-convergence-abi.adoc(spec text, not an executable exercise)boj-serverSo the producer side is exercised end-to-end, and I can find no consumer repo that runs the closure ABI through a real engine —
typed-wasmcarries only the spec. That matches the issue's own framing: it exists precisely because static verification missed two latent defects, and it is the only artifact tracking that consumers have not re-run since.Suggested action to make it closable: convert it to an explicit per-consumer checklist (which repos consume the closure ABI, each with its own real-engine exercise), then close when the checklist is green. As written it cannot be finished, because "estate-wide" has no denominator.