A leftover handle turns a finished context call into timed_out and clears the context
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 4.6k
- Forks
- 251
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 34
Description
A call in a context completes only when the guest event loop drains, and nothing runs between calls. One stray handle therefore fails an otherwise finished call and wipes the context's state.
Observed (each run in a context, then a second call to see what survived)
| Code | Result |
|---|---|
setInterval(() => {}, 50) |
timed_out; state cleared |
Start an http server (with or without server.unref()) |
timed_out; server killed; state cleared |
setInterval(...).unref() |
Returns, but the timer never fires again, even during later calls |
| Un-awaited promise on a ref'd timer | The call blocks until it settles; a concurrent call rejects with execution_busy |
Why it matters
Generated code leaves intervals and kept-alive sockets behind all the time. Losing the whole context for it is surprising, and it is the same family as the slow dispose after network use.
Proposal
Keep contexts idle-only and one call at a time, but complete a call when its top-level promise settles, and cancel leftover handles without failing the call or clearing state. Optionally add a bounded per-context queue instead of rejecting with execution_busy.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the context-call entry point and how the guest event loop, top-level promise, and leftover handles determine completion. Reproduce the listed interval, HTTP server, unref timer, and concurrent-call cases; done means settled calls retain context state, leftover handles are canceled without turning the call into timed_out, and the execution_busy behavior is resolved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, wasm
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100