Issues 225, 226 and 227 resolved with their live proofs; 232 opened and resolved #357

2026-10-04T10:37:47Z

mesh-admin commented

2026-10-04 10:37:47 +00:00

All three fixed, built, pushed and verified on the machine. The mesh reports nothing behind, nothing failed.

225 — a provisioner cannot read its grant secrets. A grant secret is now composed with the account that will read it: the node's account where the module's code is a bundle the runtime runs, its declared secrets-owner where it is still a container. The same rule a module's own secrets already followed — givenTo could never have reached these, because it claims the files a bundle's words name and the harness composes a grant secret's path from the contributions file. And the harness stops calling a permanent refusal a race (0.1.9), which is the half that cost three hours.
Proof: zero EACCES since 12:30:10 where there had been 4330, both users created, Authentication succeeded for each.

226 — the sweep collected nothing. Normalising moved into the records where the provenance is known; LetGo stays strict because it cannot tell docker.io from the mesh's own store. A reference the sweep will not address is skipped, never a reason to stop; only the store refusing ends a sweep.
Proof: the first build after the roll-out — "the artifact store let go of 200 artifact(s) the mesh no longer keeps — 1126 more to collect". The backlog falls with every build instead of standing at 1681.

227 — a container publishes only a port its module declares. Three photo modules published a bare 80 while declaring 4001/4012/4013; the mesh had nothing to assign, so 80 reached the machine and collided with the proxy. Four other modules publish 80 safely because they declare 80. A catalogue-wide test makes it a rule and named all three.
Proof: photos-admin-client up since the push, where it failed every pass.

232 — opened and resolved on the way. With the secrets readable, photos still could not connect: it asks for admin and its user lives in its own database. Invisible while 225 stood, because with no user anywhere UserNotFound for db "admin" was a complete account of that fault. Worth keeping as a habit: a fault that explains the symptom is not evidence there is only one.
Proof: photos-server up and stable.

Code: mesh-controller #263, mesh-catalog #263 and #264, mesh-sdk #22 — all merged and rolled.

All three fixed, built, pushed and verified on the machine. The mesh reports nothing behind, nothing failed. **225 — a provisioner cannot read its grant secrets.** A grant secret is now composed with the account that will read it: the node's account where the module's code is a bundle the runtime runs, its declared `secrets-owner` where it is still a container. The same rule a module's *own* secrets already followed — `givenTo` could never have reached these, because it claims the files a bundle's *words* name and the harness composes a grant secret's path from the contributions file. And the harness stops calling a permanent refusal a race (0.1.9), which is the half that cost three hours. *Proof:* **zero `EACCES` since 12:30:10** where there had been 4330, both users created, `Authentication succeeded` for each. **226 — the sweep collected nothing.** Normalising moved into the records where the provenance is known; `LetGo` stays strict because it cannot tell `docker.io` from the mesh's own store. A reference the sweep will not address is skipped, never a reason to stop; only the store refusing ends a sweep. *Proof:* the first build after the roll-out — *"the artifact store let go of 200 artifact(s) the mesh no longer keeps — 1126 more to collect"*. The backlog falls with every build instead of standing at 1681. **227 — a container publishes only a port its module declares.** Three photo modules published a bare 80 while declaring 4001/4012/4013; the mesh had nothing to assign, so 80 reached the machine and collided with the proxy. Four other modules publish 80 safely *because they declare 80*. A catalogue-wide test makes it a rule and named all three. *Proof:* `photos-admin-client` up since the push, where it failed every pass. **232 — opened and resolved on the way.** With the secrets readable, photos still could not connect: it asks for `admin` and its user lives in its own database. Invisible while 225 stood, because with no user anywhere `UserNotFound for db "admin"` was a complete account of that fault. Worth keeping as a habit: *a fault that explains the symptom is not evidence there is only one.* *Proof:* `photos-server` up and stable. Code: mesh-controller #263, mesh-catalog #263 and #264, mesh-sdk #22 — all merged and rolled.

mesh-admin added 2 commits 2026-10-04 10:37:47 +00:00

Issue 232: a consumer authenticates against a database its user does not live in 3f3fb99219

Found fixing 225: with the secrets readable the provisioner created both
users at once, and photos still could not connect because it asks for admin
while its user lives in its own database. The password was never wrong — the
grant secret and the consumer's environment hash identically.

One fault wore the other's clothes: while no user existed anywhere, the
error was a complete account of 225. Worth keeping as a habit — fix the
first and look again.

Issues 225, 226, 227 resolved with their live proofs; 232 opened and resolved ab1bd5598e

225: a grant secret is composed with the account that reads it — the node's
account for a bundle, the declared secrets-owner for a container. Zero EACCES
since 12:30:10 where there had been 4330, both users created, mongodb logging
Authentication succeeded for each. The harness also stops calling a permanent
refusal a race, which is the half that cost three hours.

226: normalising moved to the records, where the provenance is known, and a
reference the sweep will not address is skipped rather than ending the sweep.
The first build after the roll-out collected 200 and said 1126 remain — the
backlog falls with every build instead of standing at 1681 for ever.

227: the three photo modules publish the endpoint they declare, and a
catalogue-wide test makes it a rule: a container publishes only a port its
module declares, or the mesh has nothing to assign and the number escapes.

232 came out from under 225: photos asked for a database its user does not
live in, invisible while no user existed at all.

mesh-admin merged commit 438162b5a5 into main

2026-10-04 10:37:54 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#357