chore(deps): bump @morojs/engine from 1.1.4 to 1.1.7

[dependabot]

Bumps @morojs/engine from 1.1.4 to 1.1.7.

Release notes

Sourced from @​morojs/engine's releases.

v1.1.7

A correctness release with one transport improvement. Nothing on the wire changes, nothing in the API is removed or renamed, and the one new capability is additive and feature-detected through probe().capabilities. A 1.8.x/1.9.x MoroJS keeps working on this binary; a MoroJS built for this release keeps working on 1.1.6.

Fixed — callbacks now drain the microtask queue

Every trampoline into JS (onRequest, onRequestBatch, onAborted, onWritable, onWsOpen, onWsMessage, onWsClose) runs inside a Node callback scope, the same scope Node opens around its own I/O callbacks. When the outermost scope closes, Node runs the process.nextTick queue and drains V8's microtask queue.

Before this release the engine invoked callbacks with a plain V8 call, so a continuation queued during dispatch — an await on an already-settled promise, a .then chain, a framework's asynchronous not-found path — stayed queued until some later Node-managed callback ran. On a quiet server that was whatever timer fired next: a response sent from such a continuation took seconds to leave (measured: 5–29 s for a 404 or a Promise.then completion, and under load zero such responses completed). Completions that arrived through setImmediate, timers or sockets were never affected, which is why the bug hid behind real I/O.

• capabilities.callbackScope: true advertises it. A framework that armed its own setImmediate drain as a workaround can skip it when this flag is set (MoroJS does).
• Cost per callback: an async-context push/pop and, with an empty queue, one check. No measurable change in the raw hello-world numbers.
• Test: test/callback-scope.test.mjs — a response sent from a microtask, a settled await and a nextTick each leave in well under a second; the old binary fails the test by timing out.

io_uring — DEFER_TASKRUN behind a registered eventfd

The 1.1.6 measurements found io_uring halving the syscalls per request but spending more CPU per completion than libuv, because under COOP_TASKRUN every completion is its own task-work round trip. The ring now has two modes (src/uring.h, "Ring modes"):

• defer-taskrun (first choice): completions stay queued as local task work until the engine's own io_uring_enter(GETEVENTS) runs them as one batch. Such a ring posts nothing to its fd, so the loop waits on a registered eventfd, which the kernel signals when local work is queued — one extra read per wake, many completions per wake.
• coop-taskrun (the 1.1.6 mode): kept as the fallback, and selectable with MORO_ENGINE_URING_TASKRUN=coop for A/B runs (MORO_ENGINE_URING_TASKRUN=defer pins the new one with no fallback).

... (truncated)

Commits

• e2ecd4e feat: enhance loop behavior to reap pending tasks and improve wake efficiency...
• de71951 feat: enhance server stats to include transport mode and improve task handlin...
• a2e1976 chore: release v1.1.7
• 075c793 feat: add callback scope for JS callbacks and improve io_uring transport
• 8171fa2 feat: enhance batch dispatch test to handle client abort scenarios more robustly
• 2b2a10c feat: skip test for reusePort on Windows due to lack of SO_REUSEPORT support
• 497e81e feat: update fuzz tests to use std::abort for error handling and add new regr...
• b555d6a chore: release v1.1.6
• cb20a73 chore: update documentation for version 1.1.6, including changes to io_uring ...
• 899fb27 feat: add performance notes on send behavior for connection handling
• Additional commits viewable in compare view

[dependabot]

Superseded by #27.