novox/hq
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Design 25 §2: the eaten reply address is verified, not assumed

Browse Source 
A claim the whole enrolment handshake rests on, now measured against a
running server rather than reasoned from documentation — and held by a test
so it cannot become folklore if a server version changes.
This commit is contained in:
jschoubben
2026-09-27 00:15:00 +02:00
parent 53092020eb
commit 7e4da874a9
1 changed files with 8 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/25-the-bus-on-nats.md
+8 -1
View File
@@ -97,7 +97,14 @@ exactly the current declaration and nothing older. That is the wire-level answer
*is* the order, and a node that sees sequence n refuses n−1 by construction.
**A reply-to travelling through a JetStream stream is carried in the payload, never in the
transport `Reply` field.** Revision, first review: core NATS request/reply sets the requester's
transport `Reply` field.** *Verified against a running server, 2026-09-27*: a caller published
asking for a reply to `_INBOX.LCr3M83q…`, and the consumer saw a `Reply` field of
`$JS.ACK.PROBE.probe_consumer.1.1.1…`. The address is replaced, not merely at risk — so the
payload-borne reply subject below is necessary rather than defensive, and the check is a test
rather than a note, because a future server that stopped doing this would leave enrolment
working and the reason for the field quietly becoming folklore.
Revision, first review: core NATS request/reply sets the requester's
ephemeral inbox as the message's `Reply` field, and a plain responder answers it directly — but a
message a JetStream consumer delivers has already had that field claimed for the consumer's own
ack address (`$JS.ACK.<stream>.<consumer>...`), so by the time the controller (§3's CONTROL