Show HN: Chr2 – consensus for side effects (exactly-once is a lie)

Show HN (score: 6)
Found: January 11, 2026
ID: 2973

Description

Other
Show HN: Chr2 – consensus for side effects (exactly-once is a lie) Most consensus libraries (Raft, Paxos) treat the state machine as a pure black box. This is fine until your state machine needs to actually do something, like charge a credit card, fire a webhook, or send an email.

If a leader crashes after the side effect but before committing it, you get duplicates. This is my attempt at fixing this problem from first principles ish: build chr2 to make crash-safe side effects first-class citizens.

mechanism:

Replicated Outbox: Side effects are stored as "pending" in replicated state. Only the leader executes them under a fencing token.

Durable Fencing: A manifest persists the highest view using atomic tmp+fsync+rename. This ensures a "zombie" leader can't wake up and double-execute stale effects.

Deterministic Context: Application code receives a deterministic RNG seed and block_time from the log, ensuring 1:1 state transitions during replay.

Strict WAL: Entries are CRC’d and hash chained. it is designed to prefer halting on mid-log corruption over guessing.

The Trade-offs: Side effects are intentionally at-least-once; "exactly-once" requires stable effect IDs for sink-side deduplication. It’s a CP system safety over availability.

Repo: https://github.com/abokhalill/chr2

if you’ve ever had “exactly once” collapse the first time a leader died mid flight, you know exactly why I built this.

More from Show

Show HN: Control Claude permissions using a cloud-based decision table UI

Show HN: Control Claude permissions using a cloud-based decision table UI We’ve been building visual rule engines (clear interfaces + API endpoints that help map input data to a large number of outcomes) for a while and had the fun idea lately to see what happens when we use our decision table UI with Claude’s PreToolUse hook.<p>The result is a surprisingly useful policy&#x2F;gating layer– these tables let your team:<p>- Write multi-factor, exception-friendly policies (e.g. deny rm -rf &#x2F; when --force; allow cleanup only in node_modules; ask on network calls like curl&#x2F;wget; block kubectl delete or SQL DROP, each with a clear reason)<p>- Roll out policy changes instantly (mid-run, flip a risky operation from allow → ask; the next attempt across devs and agents is gated immediately– no git pull, agent restart, or coordination)<p>- Adopt lightweight governance that is somewhat agent agnostic and survives churn (MCP&#x2F;skills&#x2F;etc)- just add columns&#x2F;rules as new tools and metadata show up<p>- Get a quick central utility to understand which tools are being used, which tools get blocked most often, and why

Show HN: Claude Code Scheduler

Show HN: Claude Code Scheduler I found myself frequently wanting to schedule tasks in Claude Code (both one-time and recurring) so I built a CC plugin to help with that.<p>To install: &#x2F;plugin marketplace add jshchnz&#x2F;claude-code-scheduler &#x2F;plugin install scheduler@claude-code-scheduler<p>Then just tell Claude what you want (some examples):<p>Every Wednesday at 3am find dead code: unused functions, unreachable branches, commented-out code, and unused imports. List by file with line numbers.<p>Schedule a code review every weekday at 9am. Review commits from the last 24 hours, check for bugs, security issues, error handling gaps, and code that needs comments. Summarize with file:line references.

Show HN: Webctl – Browser automation for agents based on CLI instead of MCP

Show HN: Webctl – Browser automation for agents based on CLI instead of MCP

Show HN: Tsonic – A TypeScript to native code compiler via CLR and NativeAOT

Show HN: Tsonic – A TypeScript to native code compiler via CLR and NativeAOT

No other tools from this source yet.