Skip to content

fix: harden scalar metadata, panic fences, bun pointers, and poll locking - #2

Open
undivisible wants to merge 1 commit into
mainfrom
fix/burn-audit-hardening
Open

fix: harden scalar metadata, panic fences, bun pointers, and poll locking#2
undivisible wants to merge 1 commit into
mainfrom
fix/burn-audit-hardening

Conversation

@undivisible

@undivisible undivisible commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Implements the first hardening set from the burn audit (R1, R2, R3, R5).

Changes

  • Scalar-only generate: metadata capabilities are derived from inventory instead of advertising every reactive flag. cargo eqts already accepts explicit kind: function on schema v3; this makes README-style crates honest and adds a scalar-only parse test.
  • Panic-safe reactive ABI: catch_unwind on reactive ctor, poll, invoke (sync/async), and the napi/wasm bridges, returning ABI_PANIC / "eqts panic" instead of unwinding across extern "C". Integration tests panic in ctor, poll, and invoke.
  • Bun pointers: generated loaders no longer Number() a heap pointer. Reads go through __eqtsReadOwned (toArrayBuffer(address, …) with bigint address, capped length) and free still uses the same bigint triple.
  • Poll locking / handle IDs: registry lock is dropped before poll() (and before callback encode / object invoke). Handle allocation skips live IDs and panics if the u64 space is exhausted instead of wrapping to 1.

Tests

cargo fmt --check via cargo fmt --all, cargo clippy --workspace --all-targets --all-features --locked -- -D warnings, cargo test --workspace --all-features --locked.

Follow-ups (not in this PR)

  • Cooperative AbortSignal / join of worker threads (R4)
  • Unknown native dispose/cancelABI_UNKNOWN_HANDLE (JS currently treats cancel 14 as throw; second dispose is still ABI_OK for idempotency)
  • Mutually exclusive napi/wasm features (R6), JS identifier unification (R7), CI/release/target path work (R8–R9), UTF-8/Result parity (R10), DX cleanup (R11–R12)

Note

Medium Risk
Changes reactive registry locking, handle allocation, and many FFI entry points; incorrect behavior could cause deadlocks, handle reuse bugs, or silent pointer truncation on Bun, though coverage is strong.

Overview
This PR hardens the eqts FFI/reactive boundary and Bun codegen from the burn audit (R1, R2, R3, R5).

Metadata now derives capabilities from the export inventory (scalar-only crates no longer advertise reactive features). Tests assert the new capability shape for empty and reactive fixtures.

Reactive runtime refactors handle registration (insert_entry, allocate_handle skips in-use IDs and panics when u64 space is exhausted). poll_reactive, cancel_reactive, and callback enqueue clone Arcs and drop the registry mutex before poll() / cancel() / encoding, avoiding deadlocks when user code re-enters the registry.

Panic safety wraps reactive constructors, scalar/json exports, and setup! ABI bridges (poll, invoke, dispose, cancel) plus napi/wasm shims in catch_unwind, returning ABI_PANIC / "eqts panic" instead of unwinding across extern "C". Integration tests cover ctor, poll, and invoke panics.

Bun loaders stop coercing heap addresses with Number(); owned buffers are read via generated __eqtsReadOwned (toArrayBuffer with bigint address, length cap) while frees still use the bigint triple. Generator tests lock this in.

Reviewed by Cursor Bugbot for commit e14f188. Configure here.

…king

Derive v3 capabilities from inventory so scalar-only crates match the README
quickstart. Catch panics on reactive ctor/poll/invoke and napi/wasm bridges.
Read Bun owned buffers via bigint pointers instead of Number(), and drop the
registry lock before poll while refusing handle wrap/reuse.
@cursor

cursor Bot commented Sep 11, 2026

Copy link
Copy Markdown

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_3232b5d4-c798-430a-9310-68024cb8a5fd)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant