fix(webhook): bump local-channels pin to 0.27.1 for the filter-race fix - #620
Conversation
#618: webhook_subscribe --claim could report success while the on-disk filter file's topics silently kept the pre-call state, because FILTER_LOCK only serializes threads inside one process and the one-shot CLI/daemon never share it. defangdevs/local-channels#56 (merged, local-webhook 0.27.1) closes that with a cross-process flock on the filter file, held for the whole read-modify-write in both the CLI/MCP tool-call path and the daemon's delivery routing. Bump nix/webhook-pin.nix to the new commit and regenerate modules/agent-box.nix (nix run .#assemble). ## Verification Native aarch64 checks (this box's architecture; the pin-only diff touches no VM-test-only surface): - module-generated-up-to-date, assemble-module-escaping, golden-snapshot - one-spec-both-backends, backend-parity, multi-user, module-single-file - every other native aarch64 check in the flake (34 total), --keep-going All green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JLgCfi9EpxvsXpjvesS4JR
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe pull request updates the pinned revisions and SHA-256 hashes for the ChangesSource pin updates
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This updates pinned local-webhook and local-channels sources, including the local-webhook filter-update locking fix. No concrete current-head merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Problem
Follow-up to #618 (closed by defangdevs/local-channels#56
landing upstream, but this box — and every other deployment — still runs the
OLD pinned
webhook.pyuntil this pin moves).webhook_subscribe --claimcould report success while the on-disk filterfile's topics silently kept the pre-call state:
FILTER_LOCKis athreading.RLock, which only serializes threads inside one process, but theone-shot CLI (
agent-box-webhook subscribe, and every MCP tool call — each afresh stdio process) re-imports the module per invocation and gets its own
FILTER_LOCKsharing no memory with the long-running daemon. A CLI subscribelanding in the same window as a delivery's
route_eventwrite could eachread-modify-write the file with no ordering between the two, so whichever
write landed last silently discarded the other's change — defeating the
ownership brake from #192/#251 and risking a sibling
hook-*sessionspawning on top of work already claimed, which is exactly what happened on
DefangLabs/stationPR #38 per the original report.Change
defangdevs/local-channels#56(merged,local-webhook0.27.1) adds across-process
flockon a sibling<filter>.lockfile, held for the entireread-modify-write in both the CLI/MCP tool-call path and the daemon's
delivery routing — closing the race regardless of which process wins the
timing.
This PR bumps
nix/webhook-pin.nix(rev+sha256) to that commit andregenerates
modules/agent-box.nixvianix run .#assemble. No other filechanged by hand.
Verification
This box is aarch64, so the interactive
runNixOSTest/qcow2 checks are outof reach here (x86_64-linux-only per AGENTS.md), but the pin-only diff
touches no VM-test-only surface. Ran every native aarch64 check in the
flake,
--keep-going, all green:module-generated-up-to-datein particular confirmsmodules/agent-box.nixmatches its sources after the pin bump, and
golden-snapshotconfirms therendered configuration (including the
webhook.pyfetch) still builds andmatches the committed fixture.
I did not run the x86_64-only interactive VM tests (
sessions,settings-page, etc.) — they need a same-arch KVM guest this box doesn'thave. If CI surfaces something there, I'll follow up.
🤖 Generated with Claude Code
https://claude.ai/code/session_01JLgCfi9EpxvsXpjvesS4JR