Skip to content

rutis v0.19.3

Choose a tag to compare

@github-actions github-actions released this 31 Oct 08:53
· 288 commits to main since this release
d5aa320

rutis 0.19.3

中文 · 0.19.2 release notes

0.19.3 fixes a few bugs found after 0.19.2 and renames rutis's own two services. The rename is not compatible: plugins using those services have to change, as the first section below and Migration to 0.19 "0.19.3" say.

Read this first: rutis's own services are renamed (breaking)

  • loader becomes rutis/loader, sessions becomes rutis/sessions (#986, #992). loader and sessions are names hosts commonly give their own services, so they are left to the host now: a host's row may provide them, and a test may give a plugin fake ones. Only code using the two services changes: a plugin's inject and ctx.use (Go: Inject and ctx.Use) in any language, a row's isolate / inject in rutis.json, and commands such as rutis-host call loader.… (now rutis-host call rutis/loader.…). Rust connection plugins, hosts using Loader directly, and rutis-host/dial / rutis-host/listen rows need no change. The old names are not kept and the new ones are not suggested; the full table is in Migration to 0.19.

Test tools

  • A callback and a fake service called across each other no longer wait forever (#987, #991). In a TypeScript test, when the test called a function the plugin had handed it while the plugin called one of the test's fake services on another call chain, both sides used to wait until the process was killed. Now both return. Only the two sessions the test tool itself uses change; the sessions between a runtime and its host behave as before. The same problem in Bun and Python is still open (#994, #995).
  • A fake service whose name is taken fails only that load (#988, #993). When a service the test gave had a name the host already has, the whole test host used to disconnect and every later test failed with the host disconnected; now only that load fails and the host serves the tests after it.

Kernel

  • Cleanup errors are back in the result when dispose / shutdown interrupts a loading plugin (#983, #990). This is a regression from 0.19.2 (#969): when a pre-cancelled generation returned to Pending, its cleanup (rollback) errors went to the error sink only and were not in the result. Now, when the pre-cancellation comes from a dispose or a subtree shutdown, that generation unloads to Disposed and its cleanup errors are returned by that dispose() / shutdown(); restart, update and eviction still return to Pending and send cleanup errors to the error sink. An Err a plugin returns to cooperate with the cancellation is not reported, per diagnostic design D7.

Documentation

  • The plugin API's event example no longer hangs on Linux (#984, #989). A service method with serial then waterfall (a listener calling next) used to not return in the test, and npm test never exited; the example now passes as written. The fix is in the test driver's waiting, not in events.

Behaviour changes

Where Before Now
A plugin's inject / ctx.use, a row's isolate / inject in rutis.json, rutis-host call loader, sessions rutis/loader, rutis/sessions
TypeScript tests: a callback and a fake service call across each other Both wait; --test-timeout does not fire Both return
TypeScript tests: a fake service's name is taken The whole test host disconnects Only that load fails
dispose() / a subtree shutdown() interrupts a loading plugin Cleanup errors only in the error sink Returned by the result and kept on the final state
The plugin API's event example (Linux) npm test does not exit Passes