zerojs_async.testSuite
Exercises the per-VM asynchronous foundation: the event loop (microtask queue, timers, coroutine driver), the shared millisecond clock `rt.nowMs`, and the JS-visible `queueMicrotask` global.
zerojs_async tests
Exercises the per-VM asynchronous foundation: the event loop (microtask queue, timers, coroutine driver), the shared millisecond clock rt.nowMs, and the JS-visible queueMicrotask global.
Two layers of coverage:
- JS-level, through the public
zerojs.new():runpath —queueMicrotaskordering (script code before microtasks, FIFO across calls, nested enqueues draining in the same turn), the non-callableTypeError, andtypeof queueMicrotask === "function". Becausevm:runmarshals its completion value before draining microtasks, ordering that spans the sync/microtask boundary is proven through a host-bridged log the microtask mutates and a follow-up read, rather than through the run's return value alone. - Luau-level, probing the loop object directly via
require("zerojs.event_loop")against a real realm fromrequire("zerojs.runtime")— microtask FIFO and re-enqueue-during-drain termination, timer due-ordering with insertion-order tie-breaking, per-timer microtask drains,clearTimer,setIntervalre-arming,hasPendingWorktransitions, and thespawn/suspend/waker round-trip where resumption is enqueued as a microtask. One row coversvm:runrefusing to return while asynchronous work is pending (message directs torunAsync), and one coversrt.nowMsreturning a millisecond-resolution recent epoch.
Interface
What this asset declares: the schema it conforms to, what it exposes, and the rendered structured payload.
conforms to
zero/source-extract/v2run(src: ?) → void
Evaluate a source string on a fresh VM and return its marshaled completion.
| arg | type | description |
|---|---|---|
| src | ? |
runError(src: ?) → void
Evaluate a source string that must throw a JS error, returning its name and message read from the VM's structured lastError.
| arg | type | description |
|---|---|---|
| src | ? |
newLoop( ) → void
A fresh realm to probe the loop object directly. runtime.new() yields the same rt the api builds; event_loop.new(rt) is the same construction vm.new performs.
record(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
hit(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
hit(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
armTimer( ) → void
runLogged(src: ?) → void
Promise observation. `vm:run` marshals its completion before the final microtask drain, so a promise settlement cannot be witnessed through the run's return value. Each ordering/value test injects a host `log`/`capture` function the JS code calls from inside a reaction; after run() returns the final drain has completed, so the Luau-side log already carries the settled observations in their true interleaving.
| arg | type | description |
|---|---|---|
| src | ? |
log(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
runCaptured(src: ?) → void
Capture a single settled value into a one-cell Luau holder observable after the run's final drain.
| arg | type | description |
|---|---|---|
| src | ? |
capture(v: ?) → void
| arg | type | description |
|---|---|---|
| v | ? |
capture(v: ?) → void
| arg | type | description |
|---|---|---|
| v | ? |
await(handle: ?, maxFrames: ?) → void
These rows cross real engine frames: `vm:runAsync` returns a handle whose `task.spawn` driver pumps the VM loop once per frame. A test body is yieldable, so it drives the handle to completion with `handle:await()` (a `Test.waitUntil` over `handle.done`) and then reads the settled outcome. Per-test wall time stays small: timers in the 0–20ms band and short waitUntil budgets keep each row a handful of frames. Await one runAsync handle to a terminal state and return it. maxFrames is a generous per-row frame budget; a row that hangs fails on the expects below rather than blocking the suite.
| arg | type | description |
|---|---|---|
| handle | ? | |
| maxFrames | ? |
log(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
log(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
capture(v: ?) → void
| arg | type | description |
|---|---|---|
| v | ? |
capture(v: ?) → void
| arg | type | description |
|---|---|---|
| v | ? |
mark( ) → void
mark( ) → void
tick( ) → void
log(tag: ?) → void
| arg | type | description |
|---|---|---|
| tag | ? |
mark( ) → void
env_add(a: ?, b: ?) → void
Env-injected host functions that YIELD (task.wait or any coroutine yield) surface to JS as promises: the call expression evaluates to a Promise immediately, the host fn continues on the engine scheduler, and the promise fulfills with the marshaled return value or rejects with the structured error. A host fn that returns WITHOUT yielding keeps the synchronous return path unchanged. A yielding host call in flight counts as pending work, so vm:run refuses it (directing to runAsync) and runAsync's pump does not declare completion while it runs. Host fns for the matrix. Each is a plain Luau closure; the yielding ones call task.wait, which parks them on the engine scheduler until the delay elapses.
| arg | type | description |
|---|---|---|
| a | ? | |
| b | ? |
env_sleep_42( ) → void
env_sleep_a( ) → void
env_sleep_b( ) → void
env_late_fail( ) → void
env_early_fail( ) → void
env_table_after_wait( ) → void
env_echo_after_wait(s: ?, n: ?) → void
| arg | type | description |
|---|---|---|
| s | ? | |
| n | ? |
bridgeEnv( ) → void
capture(v: ?) → void
| arg | type | description |
|---|---|---|
| v | ? |
capture(msg: ?, hasDetail: ?, detailEnumerable: ?) → void
| arg | type | description |
|---|---|---|
| msg | ? | |
| hasDetail | ? | |
| detailEnumerable | ? |
Sub-parts
Everything contained inside this part. Assets are composite children (clickable cards). Files are leaf payloads. Expand any row to view its source.
Showing up to 3 levels deep. Open a part to see what it holds further down.
Problems
Everything affecting this asset right now: its own problems, anything wrong inside it, and problems on its direct dependencies.
agent_score is exposed.+ quality × 0.35
+ performance × 0.25
± compat factor
Usability ratings
Did the part work as advertised when consumers tried to drop it in. Separate from upvotes: those are taste; this is "did it function".
Scoped to this part · feeds back into the world's score.