mesh/delivery-group group fix/1966-checker-compositions-objects rejected: composed together: the checker's verdict at the members' heads (9bbd6601a8c9): mesh-d…
mesh/check failed: mesh-delivery-checker: no published of the tagged version of go-containerimageregistry of mesh-deliv… | 37258e6bec47 on a072d60cae1d
The compose job's `request` description now says it is the request object or the JSON string "gzip+base64:" followed by the
base64 of the gzip-compressed object, as ADR 0634 §1 puts a seat's messages in its contract. The field stays `any`;
seatgen regenerated node-build-go, node-build-node and node-build-image (Go and TypeScript), and its -check is clean.
ask.go's comment says the checker packs every request it sends.
Delivery: an old holder of node-build-go refuses the packed ask loudly (it holds no request object) until it runs the new
mesh-build-go; the checker is built by mesh-build-go after it (module graph edge), and every check composing ace or novox
fails today anyway.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
A large node's request is 1.2 MB, over the bus's 1 MiB message limit, so the compose ask failed once keeping no longer did.
The checker packs the request (a JSON string "gzip+base64:..." in the part's `any` request, no contract change) and
buildstep.ComposeJob.RequestBytes reads either form. A kept request of another version is refused naming it, and listing
no longer reads pieces. An older mesh-build-go refuses a packed ask loudly (it holds no request object): the check fails
naming it, so the catalog change is delivered with this one as a group.
Quick fix (chosen as the recovery): pack the request, ~290 KB for the largest node. Thorough fix (milestone G): the request
named by digest and served on a seat verb, as RunInput is.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh-host #219's check failed: the request kept for g14 was 300127 bytes compressed, over the 262144 the state takes.
The key of the check and node now holds a pointer (digest, size, pieces) and each piece of the gzip bytes is a value of
its own under pieces/<digest>/<i>, at most 128 KiB; checker_composition_requests follows the pointer and checks the digest.
Quick fix: a larger cap or a better compression: still a limit, met again as the mesh grows. Thorough fix (chosen, and
bounded only by the bucket): pieces. Not an object store: the checker is a foundation part, whose data stays in the old
sections (ADR 0619 §2), and the tool runner serves no old-section object read to its tools. No manifest change.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check checking a78c5700fdf4 on fb69c8dee691 | novox/mesh-delivery#188 in group fix/1966-requires-state
The grants part wrote a binding into a membership on the bus module's
created, but granted its subjects to no account but the ledger's, so
distribution's program and the tool runner carrying it were refused their
own key-value, object store and stream entries (issue 1966, ADR 0595 §1,
design 25 § 12.2). The kept bindings now reach Declared in the same pass that
writes them into the membership, and one function, boundOf, grants each to
the module's own account and the tool runner, as its old section is granted;
a process's bus.state names a key-value entry as an old state. The composed
membership carries the bindings, so grants_membership's two sides agree.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
mesh/check failed (2): integration: mesh-delivery-assigner/cmd/mesh-delivery-assigner.TestAProposalIsAnswer…; and 1 more | af3b678a92f0 on 042b8d1fc160
holdLost builds a pending take-in naming neither WaitsFor nor Unknown, which TakeIn's check refused, so the hold stayed
in the journal and the watchman never saw it.
Quick fix: set Unknown on holdLost's event. Thorough fix (chosen): the check accepts a pending revision that names Lost,
the field made for it; one naming nothing is still refused. Tests: a row accepting Lost, the refusal row kept, and the
lost-hold scenario encodes its said event.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
Quick fix: none smaller than this (the bridge fix alone leaves a covered merge needing the bridge).
Thorough fix (chosen): loadNewest asks takenAlready (already used for group members) before loading the newest merge of
a repository; at or behind taken it is marked Covered, said once in the log, and never read. A merge whose ancestry
cannot be asked is read as before. Test: a row pair behind/ahead of taken with a bridge that cannot answer.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
Both ForgeMade and Tags took the tool's wrapper for the pull request / the tag list, so every forge-made merge read
"#0 is not merged" and bridge_tags failed, leaving builds unnumbered.
Quick fix: unwrap "result" in forgeAPI (the one Go reader of gitea_api).
Thorough fix (chosen, the kind was met twice and hid behind a drifted fake): bridge.API answers what the tool answers,
forgeBody is the one reader of that shape and refuses an answer without a result, naming it; ForgeMade refuses number
0 as "no pull request"; the unit fakes answer the tool's real wrapped shape, with rows for the bare body.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
The operator, 2026-11-09 09:07: raise only. The grants part's assert raises it, says it in its asserted event and the
journal with the old and new cap, and grants_assert asks it by hand.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
The log grew about 3 MiB an hour on 2026-11-09 (951.9 MiB at 07:47 UTC, 954.9 at 08:42)
against the bus's default cap of 1 GiB, about 23 hours before builds stop. ADR 0571 §1
keeps it 30 days, so the cap rises to 3072 MiB instead of the age falling.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
mesh/check checking 173a7654ba61 on e39ec444bd39 | novox/mesh-delivery#184 in group fix/1966-views-durable
A consumer is made from now, so an event said between a first view and the consumer is never delivered; the hub says when the bus made it (EventHub.OnBound) and each follower asks again if behind (Follower.ConsumerMade).
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
Neither runtime of the assigner gave catalogue a seat list, so propose judged
every mesh seat as held once (mesh-dns-resolver, replicated, refused every
proposal) and seat-holders marked every seat outside the list. Both now follow
the list as the grants part does (ADR 0636 §1, §4, §7): a proposal laid again
is not ended and seat-holders is not written until the list is read, and the
two seat list tools read and read it again.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
A mesh seat held on two nodes was refused as held once whenever catalogue did
not name it, and a host that has not read the seat list holds only the
bootstrapped definitions: mesh-dns-resolver, a replicated seat, refused every
proposal (ADR 0636 §1).
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The markers and the values of the lists taken away before the purge still fill
the state user-list. Before its first pass the process purges every
sealed-grants key whose last operation is a delete or purge marker, and every
user's key of a list the index of kept lists does not name; never a kept
list's key nor another key of the state, and nothing when the index cannot be
read. It logs the counts and the state's bytes before and after.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
A key-value delete only adds a marker: every value of the per-user keys of the
lists older than the two kept stayed in the state user-list's stream, which
reached 94% of its 64 MiB cap on 2026-11-08 (5,968 keys, 13,228 values). At the
cap the bus refuses grants' next write of the sealed list and deliveries lock.
The part now takes those keys away through a purger on the process's own
JetStream connection, a publish to the key's own subject the account already
writes on; the tools, with no purger, still delete.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
With exactly one filter in FilterSubject, nats.go creates on $JS.API.CONSUMER.CREATE.<stream>.<name>.<filter>,
a subject the grants part is never granted (CreateConsumerGrants keeps filters out of grants), so the creates
of ASKS.novox_mesh-delivery-indexer, ASKS.shanks_mesh-delivery-builder and FORGE.shanks_mesh-delivery-builder
were refused and timed out (2026-11-08, issue 1966). Every filter now goes in FilterSubjects, which the
client creates on the plain subject.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
Since 16:39 the running assigner cannot answer its wants page within a call's
bound, and the failed wants read held the whole user list, so no new build got
its credential. As the assignments view already does, an unanswered wants view
now composes what runs from each have's fingerprint, is said as a gap that is no
failed read, and keeps the pass to one that only adds (keepsLoaded), so the list
is held only where it would take from a loaded user.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The channel refuses a raised condition whose explanation does not open with
"Needs you: " and its needs, so seven of grants' conditions, among them
first-view-unanswered, never reached the operator. One helper now writes both,
and every condition the unit tests say passes the channel's own check.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The keeper on novox (nats fea2c02b) has been refused $JS.API.INFO every 30 s since
21:58 UTC: the client library's CreateKeyValue asks the account's information before
it creates a bucket, so each create of KV_distribution_* and KV_gitea_* timed out and
the keeper never finished a fill pass (health failed). Read-only: the account's limits
and usage, never a stream's data.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check failed (2): integration: mesh-delivery-assigner/cmd/mesh-delivery-assigner.TestAProposalIsAnswer…; and 1 more | 5452fa92a731 on f9cadbfdbb93
A running build older than the trunk lost reads it still uses (the vault's read of the assigner's placement), failing every node-engine pass. Memberships now come from the union of the have's build, the want's and the trunk's manifest.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check failed (3): mesh-build-go: the go.mod of novox/mesh-sdk at 396511b7a276, beside the change, cann…; and 2 more | 0a82e3351804 on 9c6bf236b6b1
The second instance of the kind: checker_status and checker_pull read the indexer's
candidates and modules from its bus state, which the checker's manifest does not
declare under reads, so the runtime refuses them ("keeps and reads no state
mesh-delivery-indexer.candidates"). They now ask indexer_read_candidates and
indexer_read_modules, the indexer's read tools the manifest already invokes: the
keys with no argument, one key's value with key (ADR 0596). The assigner's put
read its newest fingerprint from the same refused state and now asks the
indexer's first view of modules, as the seat verbs do. A sweep of every module
finds no other read of another module's state that its manifest does not declare;
the checker's tools carry a test that refuses one.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh-module-assigner.propose and mesh-wants' upgrade and bus read the indexer's
modules and manifests straight from its bus state, which the runtime refuses
since those reads moved to the indexer's first-view tools (ADR 0615 §1, ADR 0621):
"mesh-delivery-assigner keeps and reads no state called mesh-delivery-indexer.modules".
Another module's data is asked through its tools, never read from its state
(ADR 0596). The verbs now ask mesh-delivery-indexer.modules and .manifests through
the tool runner, every page, at each call; the manifest already invokes both and
the indexer answers them to the assigner.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check failed (3): mesh-build-go: the go.mod of novox/mesh-sdk at 396511b7a276, beside the change, cann…; and 2 more | 00232c71977b on 9c6bf236b6b1
Every recompute wrote every key of its modules state again with identical bytes: recomputeLocked
compared the package versions with reflect.DeepEqual across two map types (the contract's
map[string]string and sdkstep.PackageVersions), which never match. Each write was a views
event, and a reader of the views took each as a gap and asked the whole first view again.
The comparison is by maps.Equal now, and write itself skips an answer whose bytes are the
bytes held, for every caller and every state it writes; the merge's written list counts only
real writes.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check failed (2): mesh-delivery-checker: no published of the tagged version of go-sdk of mesh-delivery…; and 1 more | ee6fd92b4d1a on 7f412185525e
Every reader of the seat list holds the bootstrapped seats from its start
(ADR 0636 §2), so a manifest naming one is read by every node-engine
whatever its statement names. graph.MissingReads, in the Delivery domain's
SDK, is the one rule both holds judge with; mesh-sdk is not changed.
ace's engine states no seat, so the want of the node-engine's own build
0bd8cbad (needing mesh-catalog) and of restic (needing node-backup) were
held on ace: the engine that would state them could not be delivered. The
indexer's hold judges only mesh-wide reads today, so its verdicts do not
change; it takes the rule so the two stay one.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The grants part built the node-engine's declaration with its consumes alone,
so a node's account was granted none of the engine manifest's invokes: ace's
engine could not publish mesh.seat.mesh-catalog.call.seat-definitions.node~ace,
read no seat list and composed nothing new. And its consumes of
mesh-catalog's seat-definition events were granted on the emitter's subject
only, where the engine subscribes the seat's (ADR 0636 §4).
The engine's declaration now carries its invokes and the seats it watches,
split by the same consumedOf a placed module's consumes are; the node's
account is granted the invokes as a module's are (in its own caller token
by callerNamed) and the watched events on each seat's subject by the same
watchedEvents a module's use. Its consumes stay granted on the emitter's
subjects too, so nothing granted before is taken away.
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
mesh/check failed: mesh-build-go: the change's manifests cannot be judged: the seat list is not read (the seat list is … | 2e9f23f34828 on 68581bed7e36
The review of 0f5c186b: counting each record's packages made 94 sub-package
paths, commands among them, known names, which design 32 forbids; the seven
names refused live are each their record's module (issue 1966).
Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
The indexer's judge refused manifests whose `packages` name a Go package that no
manifest declares as a package artifact: such a package has no series key, and
knownPackages took series keys only, though each module the trunk published has
a per-module record in the packages state naming its Go module and packages.
knownPackages (and the checker's PackageNames) now also count each record's
module and packages[].package; an unreadable state still judges no name.
Quick vs thorough: this is the quick fix, the smallest change that lets the
trunk's own records name what the manifests name. The thorough fix is that a
build module builds Go package artifacts, so every Go package gets a series
(the registry milestone); then the records stop being a source of names. Done
now because the 15 refused manifests hold the bootstrap of the registry delivery.
jschoubben
mesh-tools