Changelog

Rendered from the repository’s own CHANGELOG.md, so this page cannot drift from it. Entries are written for someone using the package: what changed, and what to do about it.

The current release is v6.0.3. Earlier releases are listed at the bottom.

v6.0.3

Released 2026-09-04.

Fixed

• ctx.reporter writes each report to the log when it fires (#487). A report used to wait in a 64-deep buffer the runtime drained at the engine’s next payload, so one made inside a long tool call surfaced only when that call ended, one made after the engine’s last payload was never written at all, and a call reporting more than 64 times lost the reports nearest its end. Every report is now appended as it is made. MAX_PENDING_REPORTS is gone with the buffer and nothing replaces it: how many reports a run may make is the log’s business, and a report made after the run completed or was cancelled is refused by the store (#471) rather than discarded on a guess. Whichever event ends a run - its own terminal payload, or the run.failed written for an engine that raised or one that just stopped - now waits for the reports the run already fired, so no report is lost to its own run ending. That wait is one store write per pending report: a run that fires thousands of reports takes thousands of writes to close, and its completion arrives that much later. The old 64-deep buffer capped the wait by dropping reports instead, which was the bug. A store that refuses a report still costs the report, never the run, and a sealed log is said once rather than once per report behind it. A report made after the run wrote its own run.failed can still land behind it, because a takeover’s run.failed deliberately seals nothing (ADR-D11 §5); #685 owns that. A consumer streaming runtime.run(...) directly still sees reports at the engine’s next payload, and an async body that reports and returns without ever awaiting still has its append land after its own call: both are #487’s second half.
• A claim that never reaches the run’s play is closed at every site that takes one, however the span is left (#470). A resume or answer whose claim committed and then met a failing ControlPort, a failing store read, or a cancellation used to leave a run the log says is RUNNING with nobody playing it, holding its session until the staleness window passed. Runtime.signal(CANCEL) against a suspended run had no cover at all, so a caller whose own task was cancelled mid-Run.cancel() wedged the very run it asked to stop. All four claim sites now record run.cancelled and free the session.
• A run that completed no longer reads back as cancelled (#471). A cancel could land behind that run’s own run.completed and leave run.status() reporting CANCELLED for a run that finished its work: written by Deck.aclose giving up on it, by a session takeover, or by the run’s own stream when a consumer broke out of async for at the completion, which needs neither of the other two. Whichever of the two events commits first is now the run’s outcome on every store, and the loser is refused with RunStateError inside the write step that would have appended it. A takeover’s run.failed still seals nothing: it is written for a run only believed dead, and one that turns out to be alive goes on writing (ADR-D11 §5).

Earlier releases