Release 0.2.0 - #8
Conversation
Minor rather than patch on purpose. Nothing was removed or renamed, so this compiles against any 0.1 code, but two changes alter behaviour and "0.1" would have delivered them through an ordinary cargo update: - an unauthenticated run now returns Err(NotAuthenticated) where it previously returned Ok with a login prompt as the answer - event payloads are bounded at 64 KiB and marked when shortened In 0.x a minor bump is the only signal Cargo treats as incompatible, so that is where a behaviour change belongs. It costs nothing here, since nothing is pinned to 0.1 yet, and it keeps patch bumps trustworthy. Adds CHANGELOG.md, shipped in the package rather than excluded: someone reading it from a vendored crate or docs.rs is exactly who it is for.
Review of #8 found the release notes describing behaviour the code does not have. Both claims were mine and both were wrong. The queued-memory bound was not a bound. Payloads were capped at 64 KiB but identifiers were exempt from every limit, so a single line could carry a 512 KiB session or tool id and 256 queued events could still reach ~128 MiB, with the pending-tool map able to retain far more since it counted entries rather than bytes. The "about 16 MiB" figure assumed a bound that did not exist. Fixed by validating identifiers rather than truncating them, which keeps the original reason for exempting them intact: a shortened session id resumes nothing and a shortened tool id matches the wrong call, so a truncated identifier is not a smaller value, it is an incorrect one. Over MAX_IDENTIFIER_BYTES an id is now rejected. An oversized session id is never captured or persisted, an oversized tool id is dropped while its event is still reported, and descriptive fields (tool name, model, quota status) are shortened since a shortened one is still meaningful. The pending-tool map now has a byte budget alongside its entry count, released when a call is answered. That gives a real ceiling: under ~21 MiB queued plus 256 KiB of pending-tool state, and the changelog now says so with the arithmetic shown rather than a figure that only held if nothing was exempt. The cancellation docs described the implementation this release replaced. They still said teardown "runs when the runtime next polls the aborted task", which is the exact dependency the Drop fix removed. Now: dropping synchronously signals the process group and cannot wait; cancel is what waits. CI now runs cargo package and checks the changelog is in it. The other steps build the workspace, not the artifact, so an `exclude` that drops a needed file would pass everything and fail at publish. Checked on every run, since that mistake is made in the commit that edits `exclude`. Tests cover each case the review named: oversized session ids across all three agents, oversized tool ids, the pending map reaching its byte budget, budget released on completion, and a worst-case line proving the per-event ceiling.
|
Review addressed in 1. The memory bound was not a boundRight, and the arithmetic checks out. Payloads were capped at 64 KiB while identifiers were exempt from every limit, so one line could carry a 512 KiB id and 256 queued events could still reach ~128 MiB. The pending-tool map was worse: it counted entries while the entries themselves were unbounded. The "about 16 MiB" figure assumed a bound that did not exist. Took the recommended fix, validate rather than truncate, because it preserves the reason identifiers were exempt in the first place: a shortened session id resumes nothing and a shortened tool id matches the wrong call, so a truncated identifier is not a smaller value, it is an incorrect one.
Real ceiling now: under ~21 MiB queued plus 256 KiB of pending-tool state, and the changelog shows the arithmetic instead of asserting a figure. All five suggested tests are in, including a worst-case line with every field at 2. Stale cancellation docsCorrect, and worse than stale: they described the exact dependency the This is the second time doc/implementation drift has slipped through here despite it being something I flag in reviews of others. Worth noting rather than quietly fixing. 3. CI does not verify the artifactAdded
Live suite re-run against all three agents: 11/11. |
1 participant
Version bump and changelog ahead of publishing.
Why 0.2.0 and not 0.1.1
The public API is purely additive since 0.1.0: nothing removed, nothing renamed, so any 0.1 code still compiles. On that basis a patch would be defensible.
But two changes alter runtime behaviour:
Err(NotAuthenticated)where it previously returnedOk(Outcome)with "Not logged in · Please run /login" as the answer.agent-abstraction = "0.1"resolves to0.1.1on a plaincargo update, so a patch would deliverOkturning intoErrsilently. In 0.x, a minor bump is the only lever Cargo treats as incompatible. It costs nothing here, since nothing is pinned yet, and it keeps patch bumps meaning what they should.Contents
Everything merged since 0.1.0: Ubicloud CI and
cargo audit, the flaky-test and audit fixes, and the three improvements adopted fromunified-agent-apiandclaude-wrapper(capability probing, auth classification, per-event bounds) plus theDropteardown fix CI surfaced.Adds
CHANGELOG.md, shipped in the package rather than excluded, since someone reading it from a vendored crate is exactly who it is for.cargo publish --dry-runpackages 19 files, 72.5 KiB compressed, and verifies clean. docs.rs built 0.1.0 successfully, so no reason to expect trouble there.Not published yet — awaiting the go-ahead, since a publish is permanent.