Reconcile: adopt initialization's consolidated HQ as canonical, re-home this session's new work #24
@@ -177,7 +177,8 @@ Struck-through rows are answered, with where. The rest are live.
|
||||
| What does a provider hand back? | Credentials and an address for a store; a command for a terminal. Same relation, different shape crossing it. |
|
||||
| Is provisioning one mechanism or two? | The mesh's own registry is provisioned **before there is a mesh**, so provisioning is part of the bootstrap and part of what the carried bundle expresses. At bootstrap the store is local; afterwards it is on another node. Same operation, both sides of a tier boundary. |
|
||||
| Is a tool surface one relation with two audiences, or two? | 56 of 126 modules carry tools — more than carry a service — and what consumes them is an **agent**, not a module. |
|
||||
| Do the remaining cross-context reads want an interface or events? | Asking *which nodes exist* is a request; reacting *when a node appears* is a subscription. Some want both. |
|
||||
| ~~Do the remaining cross-context reads want an interface or events?~~ | **Derived, not chosen.** Neither is SQL — that only ever runs against your own store. ADR 0036 makes disconnection ordinary, so anything that must work while disconnected cannot use a request and needs a local copy: a subscription. Anything where a stale answer is worse than none cannot use a subscription. |
|
||||
| What does a consumer do about events it missed while disconnected? | Replay from a point, ask once for a full picture and resume, or rebuild. The question every projection has, and unanswered here. |
|
||||
| What happens to a grant when its consumer is removed? | Dropping is data loss; keeping is a leak. ADR 0043's removal rule does not obviously carry, because the thing lives inside another module's state. |
|
||||
| Is a declaration composed per node, from what that node reported? | Some configuration follows the hardware. Either the host fills a blank — deciding, against ADR 0037 — or the control plane composes from the node's inventory first. |
|
||||
| Would `excludes` and capability requirements actually be used? | Zero manifests declare either, which is equally consistent with *nobody needs them* and *nobody can express them*. |
|
||||
|
||||
@@ -256,11 +256,38 @@ its dependency on the registry shrinks to a single table.
|
||||
What remains is a handful of genuine cross-context reads, small enough to enumerate rather than
|
||||
estimate. **The rule holds.**
|
||||
|
||||
### What it still does not answer
|
||||
### Request or subscription, and what decides
|
||||
|
||||
Whether those remaining reads want an **interface** or **events**. A consumer asking *which
|
||||
nodes exist* at the moment it needs to know is a request; one that must react *when a node
|
||||
appears* is a subscription. Some will want both, and nothing here says which.
|
||||
The remaining cross-context reads need one or the other. **Neither is SQL** — under exclusive
|
||||
ownership a module runs SQL against its own database and nothing else, whatever transport a
|
||||
query might travel over. Both options are the mesh's own channel, and both ride the broker
|
||||
([ADR 0001](../../02-DECISIONS/0001-nodes-communicate-over-a-broker.md)), so the transport is
|
||||
not the distinction.
|
||||
|
||||
**The distinction is where the answer lives when you need it.**
|
||||
|
||||
| | request | subscription |
|
||||
|---|---|---|
|
||||
| you ask | at the moment you need to know | never — you are told |
|
||||
| the answer lives | on the other side | in your own store |
|
||||
| freshness | always current | as current as the last event you received |
|
||||
| when the other side is down | you cannot answer | you answer from your copy |
|
||||
| what you must handle | a round trip that can fail | events you missed while you were down |
|
||||
|
||||
**What decides is not taste.** [ADR 0036](../../02-DECISIONS/0036-a-node-is-a-managed-machine.md)
|
||||
makes disconnection an ordinary situation rather than an exception. So:
|
||||
|
||||
> **Anything that must keep working while disconnected cannot use a request** — there is nobody
|
||||
> to ask. It needs a local copy, which means a subscription.
|
||||
|
||||
And the converse: anything that must be *correct at the instant of asking*, where a stale answer
|
||||
is worse than no answer, cannot use a subscription. A display can lag. A decision about whether
|
||||
a grant is still valid cannot.
|
||||
|
||||
That turns an apparently open question into a derived one. What remains genuinely open is
|
||||
narrower: **what a consumer does about the events it missed** while it was disconnected — replay
|
||||
from a point, ask once for a full picture and resume, or rebuild from scratch. That is the same
|
||||
question every projection has, and nothing in the record answers it yet.
|
||||
|
||||
## A migration belongs to the consumer and runs on the provider
|
||||
|
||||
|
||||
Reference in New Issue
Block a user