The grants part keeps the consumers a module has on another module's stream (issue 1921) #158

Merged
mesh-tools merged 1 commits from fix/1921-heard-consumers into main 2026-11-05 21:28:44 +00:00
Member

After #157 the stream CHECKS gained try.>, but the indexer's consumer on it never gained try.started and try.ended, so the indexer still cannot hear a try start (issue 1921). Cause: the grants part's AccountConsumers kept only consumers on EVENTS and on work queues; a consumer a module keeps on another module's stream (heardConsumer) was the controller's to make, and since the controller's removal on 2026-11-02 nobody created, kept or added to one.

  • AccountConsumers also returns each module's composed consumer on a stream it hears. The existing consumers pass creates a missing one (by its composed name, delivering from now on) and adds the filters a held one lacks, only ever adding (ADR 0640); nothing is narrowed, removed or recreated, and only the composed set is touched.
  • A restricted stream's consumer gets only what the provider's grant allows, and only for a module with an account of its own (ADR 0363 §5, ADR 0376).
  • The consumer grants follow from the same list.
  • The texts the part shows (its startup line, grants_user_list, the assertion tool) say it only ever adds.

Tested: rows in TestGrants (a reader gains exactly its granted filter once it runs as its own account, and a missing consumer is created); they fail without the change. Vet and both levels green in mesh-grants; no test function added; no manifest changed.

After delivery the grants part's next pass (or grants_compose_now) adds the try events to the indexer's consumer on CHECKS.

Reviewed-by: mesh-code-reviewer@shanks at 6f048a239c

https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i

After #157 the stream CHECKS gained `try.>`, but the indexer's consumer on it never gained `try.started` and `try.ended`, so the indexer still cannot hear a try start (issue 1921). Cause: the grants part's `AccountConsumers` kept only consumers on EVENTS and on work queues; a consumer a module keeps on another module's stream (`heardConsumer`) was the controller's to make, and since the controller's removal on 2026-11-02 nobody created, kept or added to one. - `AccountConsumers` also returns each module's composed consumer on a stream it hears. The existing consumers pass creates a missing one (by its composed name, delivering from now on) and adds the filters a held one lacks, only ever adding (ADR 0640); nothing is narrowed, removed or recreated, and only the composed set is touched. - A restricted stream's consumer gets only what the provider's grant allows, and only for a module with an account of its own (ADR 0363 §5, ADR 0376). - The consumer grants follow from the same list. - The texts the part shows (its startup line, `grants_user_list`, the assertion tool) say it only ever adds. Tested: rows in `TestGrants` (a reader gains exactly its granted filter once it runs as its own account, and a missing consumer is created); they fail without the change. Vet and both levels green in mesh-grants; no test function added; no manifest changed. After delivery the grants part's next pass (or `grants_compose_now`) adds the try events to the indexer's consumer on CHECKS. Reviewed-by: mesh-code-reviewer@shanks at 6f048a239ca3ddeff1e5179a96d6069c0474c726 https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
mesh-tools added 1 commit 2026-11-05 21:18:56 +00:00
The grants part keeps the consumers a module has on another module's stream: created, and only ever gaining filters (issue 1921)
mesh/check being carried to 6f048a239ca3 on c0e5bc2834fe | from fab533dfd0cd
mesh/delivery merged: source.main moved to novox/mesh-delivery@c0e5bc2834fe
6f048a239c
Claude-Session: https://claude.ai/code/session_01NcbgfFSnn24M3GcqttoU7i
Author
Member

Delivery novox/mesh-delivery@6f048a239ca3 — merged since 2026-11-05T21:28:47Z

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

Transitions

  • 2026-11-05 21:18 (new) → proposed (announced): novox/mesh-delivery#158's head announced
  • 2026-11-05 21:19 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-05 21:28 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-delivery:view --> **Delivery** `novox/mesh-delivery@6f048a239ca3` — **merged** since 2026-11-05T21:28:47Z **Source** — source.main moved to novox/mesh-delivery@c0e5bc2834fe. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-11-05 21:18 (new) → proposed (announced): novox/mesh-delivery#158's head announced - 2026-11-05 21:19 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-05 21:28 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 c0e5bc2834 into main 2026-11-05 21:28:44 +00:00
mesh-tools deleted branch fix/1921-heard-consumers 2026-11-05 21:28:44 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-delivery#158