Are your "extensions" unnecessary with WIT native future and stream?

[tv42]

Hi. Interesting project.

It seems https://obeli.sk/docs/latest/concepts/extensions/ is kinda unnecessary now with the latest WIT work now having native future<T> and stream<T> types.

https://github.com/WebAssembly/component-model/blob/main/design/mvp/Concurrency.md

Interested to hear what you think about that.

[tomasol]

You're right that the shapes line up: a future<T> from an async import is basically what -submit + -await-next encode, and a join set is close to a waitable-set.

Obelisk workflows are obviously replayable because the runtime holds no live guest state: with the interrupt strategy the instance is destroyed on every await point, and even with the default strategy the execution can be transparently unloaded from memory if it makes no progress for some time.

Native async works the opposite way, keeping live executor continuations in guest memory, so you'd have to snapshot and reconstruct that state, which is far harder to observe and reason about than the JSON events of an execution log. That state would also likely be tied to a specific compiler + wit-bindgen version, whereas Obelisk only cares that two components produce the same events, which are human- and LLM-readable. So with a Rust execution sitting paused, an LLM could generate a JS function that emits the same events to that point, which is a viable way to ad-hoc migrate a stuck execution or clean up some buggy edge case.

The nondeterminism surface also gets much bigger. The async ABI exposes a lot more of it directly to the guest (see the spec's Nondeterminism section): which waitable fires first, whether a thread blocks or continues, resume order, backpressure release order, which thread gets a cancellation.

The scopes don't match either. In the async ABI a callee's lifetime is bound to the caller's task. In Obelisk a single workflow creates and closes many join sets, and closing one has its own semantics: unawaited activities and cancellable child workflows are cancelled, non-cancellable ones are awaited. More broadly, Obelisk has its own semantics around pausing and cancellation that aren't compatible with the async ABI's model.

It's also a deliberate programming model. Workflows are meant to read as simple sequential programs, with async/await and callbacks kept out of workflow code; native futures would reintroduce exactly that surface. Underneath, join sets sit very close to the deterministic state machine the engine runs, which is why the extensions aren't just a convenience layer: they are its API surface.

Same for stream<T>, only more so: it doesn't map onto the workflow boundary at all, since every element would have to be journaled. It fits inside a single activity (HTTP bodies, token streams), which in principle should work.

[tv42]

I'll admit I haven't dug into the Obelisk implementation much at all. I sort of assumed it recorded calls over WIT as (function_name, args) -> return_value and reran the work as needed, replaying old recorded responses. This to me seems like it would work with the native future/stream (with the usual caveats about how steps should be made deterministic by programmer). Yes, timing might be different, but any old call would get the same old result, so the end result should be equivalent. I understand this is how e.g. DBOS Transact or Windmill handles durability (regardless of whether they have concurrency; I don't really know).

In Obelisk a single workflow creates and closes many join sets, and closing one has its own semantics: unawaited activities and cancellable child workflows are cancelled, non-cancellable ones are awaited.

Dropping a future/stream has similar properties.

Anyway, thank you for your thoughts. I need to understand your join sets better to continue my exploration.

[tomasol]

I sort of assumed it recorded calls over WIT as (function_name, args) -> return_value and reran the work as needed, replaying old recorded responses.

Yes,that's exactly what happens, but it is always wrapped in a join set. If using the regular WIT bindings (not the extensions), all 3 events (Join set create, Submission with recorded params, Join next) are produced.

I realize the previous reply may sound too dismissive. In fact, I do like the ergonomics of:

let futures = FuturesUnordered::new();
futures.push(first_fn(...));
futures.push(second_fn(...));
let result = futures.next().await;

over having to map responses to their types explicitly on an heterogeneous join set:

let join_set = join_set_create();
let a = first_fn_submit(&join_set, ...);
let b = second_fn_submit(&join_set, ...);
let (response_id, _) = join_next(&join_set)?;
let ResponseId::ExecutionId(execution_id) = response_id else {
    unreachable!("delay request was not submitted");
};
let result = first_fn_get(&execution_id)?; // or second_fn_get, based on id

The biggest worries are:
A. complexity of making the host executor deterministic
B. uncertainty whether it can be achieved without snapshotting or adding fine-grained executor-shaped events.
C. cancellation customization: the cancel/close policy must stay compatible with today's semantics and be driven by Obelisk, not the ABI
(should be possible)
D. forbidding multi-tasking inside a workflow, since it breaks the linear execution order

I have a small prototype for B and it looks using the current coarse-grained events is feasible.

If those can be overcome, the async version with a single implicit per-workflow join set could achieve 80% parity with what can be expressed with explicit join sets and would be a worthy addition, especially from UX standpoint.