ADR 0188: a provider declares what it derives for each consumer, and the mesh tells both ends (issue 124) #303

2026-10-02T19:27:17Z

mesh-admin commented

2026-10-02 19:27:17 +00:00

Group 8's first half.

Context. Everything about an arrangement is delivered by the mesh — where the provider is, which port, what name to present, where the password is. One kind of value escaped: where the provider names the resource, the name is derived per consumer, serves is literal, and a provisioner returns nothing. So the object store's bucket rule lived twice — in minio's TypeScript, and transcribed by hand into all three consumers' definitions. One of the three named a predecessor's bucket and would have authenticated successfully and been refused on every object. Even corrected, each of the three names the machine the module happens to run on.

Decision. A served value may name the consumer the mesh is serving: ${consumer:as} and ${consumer:as:dns}, and nothing else — the mesh learns no protocol here; it spells its own name in an alphabet it already knows. Filled once, where the consumer is known, and delivered to both ends from the one resolution. A consumer may no longer write the derived value into its own definition.

The rejected alternative — a provider returning values from provisioning — is weighed in the record: it would make a grant carry data the provider wrote, make a consumer's declaration wait on its provider's reconcile loop, and put the rule where nothing can refuse it.

Design 27 amended; issue 124 resolved; all three checks pass.

Code, with its merge order: mesh-controller #225 first, mesh-sdk #10 second (published as 0.1.2), mesh-catalog #228 last.

Group 8's first half. **Context.** Everything about an arrangement is delivered by the mesh — where the provider is, which port, what name to present, where the password is. One kind of value escaped: where the provider *names the resource*, the name is derived per consumer, `serves` is literal, and a provisioner returns nothing. So the object store's bucket rule lived twice — in minio's TypeScript, and transcribed by hand into all three consumers' definitions. One of the three named a predecessor's bucket and would have authenticated successfully and been refused on every object. Even corrected, each of the three names the machine the module happens to run on. **Decision.** A served value may name the consumer the mesh is serving: `${consumer:as}` and `${consumer:as:dns}`, and nothing else — *the mesh learns no protocol here; it spells its own name in an alphabet it already knows*. Filled once, where the consumer is known, and delivered to both ends from the one resolution. A consumer may no longer write the derived value into its own definition. The rejected alternative — a provider returning values from provisioning — is weighed in the record: it would make a grant carry data the provider wrote, make a consumer's declaration wait on its provider's reconcile loop, and put the rule where nothing can refuse it. Design 27 amended; issue 124 resolved; all three checks pass. **Code, with its merge order:** mesh-controller #225 first, mesh-sdk #10 second (published as 0.1.2), mesh-catalog #228 last.

mesh-admin added 1 commit 2026-10-02 19:27:17 +00:00

ADR 0188: a provider declares what it derives for each consumer, and the mesh tells both ends 0b9fc90885

Issue 124: a value the mesh's own rule produced reached neither end as a
statement. The object store's provisioner derived each consumer's bucket in
its own code; all three consumers transcribed the rule into their own
definitions, one of them wrong, and each of the three also named the machine
it happens to run on.

A served value may now name the consumer the mesh is serving. Design 27
amended; issue 124 resolved.

mesh-admin referenced this pull request

2026-10-02 19:50:12 +00:00

Group 8: ADR 0201 (a provider declares what it derives, issue 124) and ADR 0189 (the store keeps what the records name, issue 108); issue 202 #305

mesh-admin closed this pull request

2026-10-04 00:46:04 +00:00

mesh-admin commented

2026-10-04 00:46:13 +00:00

Closed in favour of #305, which now carries both of group 8's records.

Two days of main moved under this: the bundles refactor took ADR 0188, so this record is now ADR 0201 (the renumber is noted in the record itself — only the number moved). Rebasing both halves together was the safe way to do that; splitting them apart again afterwards is the manoeuvre that has cost a session before, and they were always going to merge in the same window.

#305 has the whole of group 8 and the merge order.

Closed in favour of #305, which now carries both of group 8's records. Two days of main moved under this: the bundles refactor took **ADR 0188**, so this record is now **ADR 0201** (the renumber is noted in the record itself — only the number moved). Rebasing both halves together was the safe way to do that; splitting them apart again afterwards is the manoeuvre that has cost a session before, and they were always going to merge in the same window. #305 has the whole of group 8 and the merge order.

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#303