Release v0.6.1

[kwsantiago]

Cuts 0.6.1. Five commits have been sitting on main since 0.6.0, three of which fix ways a remote peer could crash, wedge or confuse the relay.

Why now

0.6.0 is what is currently published, and these are not cosmetic:

• Release handover connections directly instead of through disown() #181 connections dropped from every tracking list: 42 leaked descriptors and a core pinned at 99.6% after load stopped, reachable unauthenticated
• Publish a handover connection only after releasing its mutex #183 a connection recycled while another thread still held its lock. Aborts on a safety-checked build; on the release build a later connection can inherit an already-held lock, putting two threads in one connection's list bookkeeping. Reachable unauthenticated by driving connection churn
• Run the accept teardown once, and guard the shutdown union read #184 connection setup running its whole cleanup twice, self-linking the record on the free list. Not directly remote: needs the kernel to refuse the socket registration
• Fix the Nix package build and guard it in CI #182 the Nix package build, failing since 0.5.12

Version drift, which is why this touches six files

The version lives in four places and only two of them were checked. nix/package.nix had already drifted, reporting 0.5.10 for two releases before #182 caught it. The other unguarded copy is the one users actually see: src/nip11.zig is what the relay reports over the wire.

scripts/verify-nix-deps.sh now checks all four against build.zig.zon as the source of truth. Mutation-tested by breaking each independently:

• nix/package.nix → caught
• src/main.zig (startup log) → caught
• src/nip11.zig (NIP-11 document) → caught

Verified over the wire rather than by reading the diff: the built relay logs Wisp v0.6.1 starting and answers NIP-11 with "version":"0.6.1".

Release notes

The changelog entry describes each fix in terms of what a relay operator would observe, not in terms of the internals. Where a bug behaves differently between the safety-checked and release builds, it says so, since that difference determines whether an operator sees a crash or silent corruption.

Verification

zig build test 65/65, protocol suite 45/45, verify-nix-deps.sh and verify-vendored-httpz.sh both clean.

Not blocked on upstream

Worth recording since it has come up: the relay builds from vendor/httpz, not from an upstream fetch, and CI gates the vendored tree against upstream plus vendor/httpz.patch. Whether upstream adopts these fixes changes nothing about what this release contains. Upstreaming remains worth doing to retire the cost of re-applying the patch on every re-pin, but it is not a release gate.

Review follow-up: six factual errors in the release notes, corrected

The review was pointed at accuracy of the operator-facing text, and it found six wrong claims. Each is verified against git history, not just accepted:

claim	reality	how checked
Nix build broken "since httpz was vendored in 0.5.15"	the WebSocket pin moved at v0.5.12, a month earlier; the stale httpz entry was inert	git log -S on the hash in build.zig.zon
version stale "for two releases"	six: v0.5.11 through v0.6.0	git tag --contains 424e2f0
#180 fixes the timeout sweep	that shipped in 0.5.15 (#166) and is already in this changelog; #180 changes nothing for an operator on 0.6.0	read the 0.5.15 entry
#183 can "leave two live sockets sharing one connection record and send a reply to the wrong client"	that is #184's mechanism, not #183's. #183's consequence is a stolen lock, so two threads end up in one connection's list bookkeeping	the #183 commit and PR
"each is covered by a test or an invariant check that fails without it"	true only for #181 and #182. #183 and #184 add logging that does not fail	git show --stat on both
"three ways a remote peer could crash"	two. #184 needs the kernel to refuse a registration and is not directly attacker-controlled	#184's own text

Also corrected: #184's trigger is memory pressure or the per-user watch limit, not memory pressure alone.

Two non-factual fixes from the same review: bullets are now single unbroken lines matching every other entry in the file, since wrapped bullets render as ragged line breaks in a GitHub release body; and ### Changed now precedes ### Fixed, matching 0.6.0 and Keep a Changelog.

And a real bug in the new script: under set -euo pipefail, zon_version="$(grep ... | head -1)" exits the script the moment grep finds nothing, so the friendly "could not read .version" message below it was unreachable and CI would have shown a bare exit 1. Fixed and verified by breaking build.zig.zon deliberately: the message now prints.

Summary by CodeRabbit

• New Features

  • Released version 0.6.1 with updated application and protocol metadata.
  • Added release notes covering connection-handling improvements, packaging updates, and integration coverage.

• Bug Fixes

  • Improved connection handling for more reliable operation.

• Chores

  • Updated package versions across supported distribution formats.
  • Improved version consistency checks to catch mismatched release information.

[coderabbitai]

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the primary change: releasing version v0.6.1.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch release/v0.6.1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}