An assigner ask that lapsed or was cancelled at the operator channel while its key still stands
was never asked again: the router drops a second ask under an id it keeps, and the assigner
only writes a new asking when the key is absent (note 151: the nats yes on novox and three
backup asks). The teller now says ask-ended (its module event, emits; body in its own package
tellerevents, ADR 0634 §1) when the router records such an end, and when a watch hands it a key
standing under an asking that ended so, which covers its start and the asks standing now. A
refusal, a replacement, an answer and an end by hand (teller_end_ask, kept in its own record)
are not said.
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
The assigner took record.novox.nats away as stale in the same second the operator's yes
was written (the yes counts only while the ask is there), and rewrote it under the id the
router already kept, so the teller never asked it again. The stale test compared a module's
ask with the whole node's composition; it now reads the module's own have, and restore and
record asks are numbered by their writing's time as hold asks are.
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
The hold named the same commit twice when only a mesh package moved. It now names both builds
by fingerprint with their commits, the input that moved when the commit is the same, and says a
newest build that failed as failed with its first words.
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
A put with hold false waited for the node's composition digest to equal its own and never ended when the node composes its own,
pinning the module's want (issue 1966, F21).
Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
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 failed (6): integration: mesh-delivery-indexer/cmd/mesh-delivery-indexer.TestIndexerWritesModule…; and 5 more | 3a63813b3d75 on fb69c8dee691
mesh/delivery closed: a newer head of the same pull request
An indexer that started while the bus's storage was down read no published package,
took every import for unpublished and wrote the version line over ~130 modules'
fingerprints, which a later pass kept through the build's shortcut. A failed or empty
read of the packages state, where held modules were computed from published ones,
now fails the pass and says why; a version line clears the import form it was
computed beside; indexer_fingerprints_again computes the import form again by hand,
acting first and recording the hand act after, with a bound.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
The verbs ask mesh-delivery-indexer.modules and .manifests through the tool runner
since the asks moved off the indexer's state, but the test's stand-in answered every
ask {ok:true}, which is no answer: propose failed on main with 'unexpected end of
JSON input'.
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
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
jschoubben
mesh-tools