This PR makes the test_futures.ts tests run in series.
This makes it easier to test/demonstrate that:
the async-callbacks are cleaned up (so we can use this to keep the promise in memory, and have a future place for an AbortController to live)
the async-rust-call are cleaned up.
Additional tests/documentation is also put in place for a future implementation of task cancellation, both Rust cancelling JS and the other way round.
This hasn't been implemented here:
for Rust cancelling JS: AbortController exists, but doesn't seem to be widely adopted. It is not yet implemented by Hermes.
for JS cancelling Rust: an FFI method can be easily exposed, but it is not clear what the most JS-ergonomic way to do this might be.
for Rust cancelling Rust, and it propagating to JS: I'm not 100% sure, but I don't think it is currently supported by uniffi-rs.
There seems to be missing tests for this case: Swift test, Kotlin test. Missing is the case where timeoutMs < releaseAfterMs, such that the Rust aborts after the timeout.
This PR makes the
test_futures.tstests run in series.This makes it easier to test/demonstrate that:
async-callbacksare cleaned up (so we can use this to keep the promise in memory, and have a future place for an AbortController to live)async-rust-callare cleaned up.Additional tests/documentation is also put in place for a future implementation of task cancellation, both Rust cancelling JS and the other way round.
This hasn't been implemented here:
AbortControllerexists, but doesn't seem to be widely adopted. It is not yet implemented by Hermes.timeoutMs<releaseAfterMs, such that the Rust aborts after the timeout.CALL_CANCELLED, andfatalErrors on detection.