Grants composes from the haves while the wants view is unanswered, and its conditions reach the operator (issue 1966, recovery) #180

2026-11-08T22:31:52Z

mesh-tools commented

2026-11-08 22:31:52 +00:00

Recovery fix (instruction section recovery-fixes-merge-and-tell; the operator's full permission to deliver design 47).

Symptom. Since 16:39 UTC grants has held the bus user list: "held: the list in force is kept while a read of this pass failed (mesh-delivery-assigner.wants …)". The wants first view never answered (226 asks). A 386-key page from the assigner on ace takes about 40 s, against a 30 s call bound in the runtime and in mesh-sdk process. While the list is held, no new build of any module gets a credential. Grants also raised conditions that the operator channel refused for their wording, so the operator never saw them.

Fix.

e7779d2a: every grants condition's explanation opens with "Needs you: ", as the operator channel requires. Seven conditions were refused before.
e79a546e: while the wants view does not answer, a pass composes what runs from each have's fingerprint, as placeByHaves already does for an unanswered assignments view. The gap is not a failed read, and the pass only adds (keepsLoaded).
160fca6a: the log says how long each first-view page took.

Quick or thorough. This is the quick part, and it breaks the lock. The thorough fix comes next: the owners' processes answer their first views from memory, as ADR 0615 §3-§4 holds (the operator's answer, 2026-11-03), undoing ADR 0621's tools runtime. That needs a decision first, because a process cannot serve a call today (ADR 0436 clause 4).

Checked locally. go vet ./..., go vet -tags integration ./... and go test ./... in modules/mesh-grants. Each test fails without its fix.

Undo. Revert this merge.

https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5

Recovery fix (instruction section recovery-fixes-merge-and-tell; the operator's full permission to deliver design 47). **Symptom.** Since 16:39 UTC grants has held the bus user list: "held: the list in force is kept while a read of this pass failed (mesh-delivery-assigner.wants …)". The wants first view never answered (226 asks). A 386-key page from the assigner on ace takes about 40 s, against a 30 s call bound in the runtime and in mesh-sdk process. While the list is held, no new build of any module gets a credential. Grants also raised conditions that the operator channel refused for their wording, so the operator never saw them. **Fix.** - e7779d2a: every grants condition's explanation opens with "Needs you: ", as the operator channel requires. Seven conditions were refused before. - e79a546e: while the wants view does not answer, a pass composes what runs from each have's fingerprint, as `placeByHaves` already does for an unanswered assignments view. The gap is not a failed read, and the pass only adds (keepsLoaded). - 160fca6a: the log says how long each first-view page took. **Quick or thorough.** This is the quick part, and it breaks the lock. The thorough fix comes next: the owners' processes answer their first views from memory, as ADR 0615 §3-§4 holds (the operator's answer, 2026-11-03), undoing ADR 0621's tools runtime. That needs a decision first, because a process cannot serve a call today (ADR 0436 clause 4). **Checked locally.** `go vet ./...`, `go vet -tags integration ./...` and `go test ./...` in modules/mesh-grants. Each test fails without its fix. **Undo.** Revert this merge. https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5

mesh-tools added 3 commits 2026-11-08 22:31:53 +00:00

Open every grants condition's explanation as the operator-channel requires (issue 1966, recovery) e7779d2afd

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

Compose what runs from the haves while the wants view is unanswered (issue 1966, recovery) e79a546eb7

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

Say in grants' log how long each first-view page took (issue 1966, recovery)

mesh/delivery merged: source.main moved to novox/mesh-delivery@7d8e2060a740

Details

mesh/check checking 160fca6a4767 on 7d8e2060a740

160fca6a47

The wants page failed 226 times on a call's bound with nothing in the log to
show how far from it the answer was.

Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5

mesh-tools commented

2026-11-08 22:31:57 +00:00

Delivery novox/mesh-delivery@160fca6a4767 — merged since 2026-11-08T22:32:06Z

Source — source.main moved to novox/mesh-delivery@7d8e2060a7. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Transitions

2026-11-08 22:31 (new) → proposed (announced): novox/mesh-delivery#180's head announced
2026-11-08 22:31 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
2026-11-08 22:32 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

**Delivery** `novox/mesh-delivery@160fca6a4767` — **merged** since 2026-11-08T22:32:06Z **Source** — source.main moved to novox/mesh-delivery@7d8e2060a740. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-11-08 22:31 (new) → proposed (announced): novox/mesh-delivery#180's head announced - 2026-11-08 22:31 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false) - 2026-11-08 22:32 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.

mesh-tools merged commit 7d8e2060a7 into main

2026-11-08 22:31:58 +00:00

mesh-tools deleted branch fix/1966-first-view-one-read

2026-11-08 22:31:59 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-delivery#180