One toolchain across the estate. The tree carried 1.26.0, .1, .3, .4 and .5
at once, so which compiler built a binary depended on which repo it came
from.
Co-authored-by: Hanzo Dev <[email protected]>
hanzoai/ci keeps the reusable at .github/workflows/build.yml — the one path
both planes resolve, since github.com reads a reusable only from there and the
forge reads it too. The v1 tag moved with it, so a caller still naming
.hanzo/workflows/build.yml asks for a blob that is not in the tree:
InsertRun: read hanzoai/ci@v1:.hanzo/workflows/build.yml: object does not exist
The caller itself stays at .hanzo/workflows/cicd.yml on purpose: github.com has
no runner for these labels, so a caller placed there could never be scheduled.
Co-authored-by: Hanzo Dev <[email protected]>
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
It was Fencer, which named the wrong actor. Fencing is what the STORE does
when it refuses a stale round; an interface that hands back a lease fences
nothing. The value it yields is a Lease, so it is Leases -- the same shape as
db.Namespaces resolving a namespace to a handle.
Recorded in the doc why it is not the other candidates, because each is
tempting and each is wrong in an instructive way: Writer has no write method
and already means something you write TO; Consensus names one possible source
when StaticLeases returns Round 1 from a single process and CAS consults a
single register, neither reaching agreement; Leader implies one leader when
Owner is per-KEY, so a thousand keys have a thousand owners.
Prose still says fencing where it describes the store refusing a stale round.
That is the accurate use, and keeping it is what makes the rename legible.
Identifiers only -- no behaviour change. Breaking for importers, so this is a
minor bump and cloud moves on its own commit.
Co-authored-by: Hanzo Dev <[email protected]>
Election is coordination-free, so two replicas with divergent membership
views can each elect themselves the single writer for a key (split-brain),
and election has no way to make a deposed writer stop. Add the composable
fencing VALUE and SEAM that close this, with no I/O and no consensus folded in:
- Round uint64 monotone fencing epoch (the only value into storage)
- Lease{Key,Owner,Round} binds an elected owner to the round it writes at
- Fencer.Acquire seam round source plugs in behind it (linearizable store
today, Lux BFT round tomorrow) — never in this package
- StaticFencer(self) single-process fencer (round 1), mirrors Static
Invariant: round monotone per key, strictly increases on handoff, so a new
lease outranks every prior holder and the store (vfs/replica.FencedStore)
fences the old writer by refusing any lower round.
Election is coordination-free, so two replicas with divergent membership
views can each elect themselves the single writer for a key (split-brain),
and election has no way to make a deposed writer stop. Add the composable
fencing VALUE and SEAM that close this, with no I/O and no consensus folded in:
- Round uint64 monotone fencing epoch (the only value into storage)
- Lease{Key,Owner,Round} binds an elected owner to the round it writes at
- Fencer.Acquire seam round source plugs in behind it (linearizable store
today, Lux BFT round tomorrow) — never in this package
- StaticFencer(self) single-process fencer (round 1), mirrors Static
Invariant: round monotone per key, strictly increases on handoff, so a new
lease outranks every prior holder and the store (vfs/replica.FencedStore)
fences the old writer by refusing any lower round.
HRW (Rendezvous) single-writer election as its own coordination primitive
— no coordinator, lock service, Postgres, or Redis. Answers "who is the
single writer for key K" identically on every replica.
Extracted from hanzoai/vfs/replica/owner.go (HIP-0107), which was
storage-agnostic pure Go with no vfs-internal callers. Election (who
writes) and replication (how state ships) are orthogonal; this is the cut.
Generalizes orgID -> key (any ownership unit).
API: Member, Owner, IsOwner, Replicas + the Membership seam + Static.
Zero deps (stdlib crypto/sha256, encoding/binary, context).
zeekayandHanzo Dev