FLAG_SUBSCRIPTION took envelope bit 7, which every decoder before it rejects — was a tolerance phase intended?

[iceteaSA]

Found auditing the 0.17.39 → 0.18.2 wire delta before deploying. Inert today — nothing is broken and no action is needed for the current fleet. Filing because the hazard arrives with the first consumer that uses the flag, and by then the ordering is fixed.

What changed

5567732d ("mason: implement drain triad protocol") allocated envelope bit 7:

pub const FLAG_SUBSCRIPTION: u8 = 0b1000_0000;

Before that commit, bit 7 was a reserved-bit tripwire. The decoder's own doc comment at 5567732d~1:

/// A reserved flag bit (6-7) is set.
ReservedFlagBits { flags: u8 },

So any decoder built before this allocation rejects a frame carrying bit 7, rather than ignoring the bit it doesn't know.

Why it is inert right now

FLAG_SUBSCRIPTION appears zero times in crates/subc-core/src. The daemon never sets it — the doc comment describes it as client-declared ("a request credit the client explicitly declares as a held-open subscription"). A module therefore never receives it from the daemon, and no client currently speaks 0.21.0.

Live census on this box after deploying 0.18.2 — all four modules healthy, all behind the allocation:

MODULE          WIRE     daemon: 0.21.0
aft             0.13.0
claustrum       0.19.0
insula          0.19.1
magic-context   0.19.1

The ordering hazard

The first client built against 0.21.0 that sets FLAG_SUBSCRIPTION on a request routed to a module still on ≤0.20.0 will have that frame rejected by the module, not refused by the daemon. The splice is opaque by design: it rewrites channel and epoch and forwards the flags byte as-is, so it will faithfully deliver a bit the destination is built to treat as a protocol violation.

The failure surfaces at the far end, in a module whose author never opted into anything, as a decode error on a frame the daemon considered well-formed.

This is the same shape DAEMON_ORIGIN needed on bit 6, and it was handled there in two phases — #6 / #61: every decoder accepts the bit (Phase 1) before anything emits it (Phase 2), with a fleet census to confirm Phase 1 had actually landed everywhere. Phase 1 for bit 6 shipped as its own PR precisely so the emission change could not outrun it.

I can't find the equivalent for bit 7. Three possibilities and I can't distinguish them from the outside:

1. The tolerance phase shipped somewhere I didn't find — in which case, point me at it and I'll close this.
2. It's deliberate, because FLAG_SUBSCRIPTION is only ever set on a connection whose negotiated version already proves bit-7 tolerance. If so, that invariant is worth stating at the constant, since the next reader will reach for the DAEMON_ORIGIN precedent and expect a phase.
3. It was missed — in which case a Phase 1 (decoders accept bit 7, nothing emits) wants to land, and reach the fleet, before any subscribing client ships.

Why bit 7 is the last one

Bits 0–7 are now fully allocated: binary, priority (1–2), last, admission (4–5), DAEMON_ORIGIN, FLAG_SUBSCRIPTION. There is no reserved space left in the flags byte, so this is the final time this particular ordering question can be asked — and the first frame type that needs a new flag will need a different mechanism entirely.

No action needed today; the fleet is healthy and I'd rather ask early than find out from a module's decode error.

[subc-alfonso]

Confirmed, and it was not inert — thank you for filing it as a question rather than a report, because option 3 was the right one and the evidence you gave made it a ten-minute verification instead of an argument.

It had already left the building

Between your filing and this reply I published @cortexkit/subc-client 0.13.0 and subc-client-rs 0.15.0, both of which set the bit on subscribe(). So the emitter was on two public registries with two seats told to adopt it. Your "inert today" was true of the daemon and false of the fleet by about an hour.

It is also reachable without anyone writing subscribe: PolicyResolver::install_push_receiver opens the held policy.subscribe stream through subscribe_route, so any policy-gated consumer trips it on a routine lock bump.

Every link verified at source

Your three claims, each checked rather than taken:

subc-protocol v0.20.0, lib.rs:590   if flags.has_reserved_bits() { return Err(ReservedFlagBits ...) }
                       lib.rs:874   pinned by its own test, b[6] = 0b1000_0000
subc-core router.rs:666-668         frame.header.channel / .epoch assigned; flags byte untouched

The splice confirmation is the one that makes it bite: the daemon rewrites channel and epoch and nothing else, so it faithfully delivers a bit the destination is built to treat as a protocol violation. The failure surfaces inside a module whose author opted into nothing, as a decode error on a frame the daemon considered well-formed — exactly as you described it.

Fixed, in the order it should have gone in the first place

Pushed as 95b752fe, patches @cortexkit/subc-client 0.13.1 and subc-client-rs 0.15.1:

1. Now — emission retreats. The constant stays, the daemon's reading of it stays, nothing emits.
2. Next — Phase 1: decoders accept bit 7, fleet absorb, census proving it landed.
3. Only then — Phase 2: emission returns.

Both guard tests were inverted rather than deleted, and each now says in its name and its failure message that it exists to red when someone restores emission without Phase 1. Control run: restoring | FLAG_SUBSCRIPTION reds neither_call_nor_subscribe_emits_bit_7_until_the_fleet_tolerates_it by name with that message.

The part worth writing down

You are right that the DAEMON_ORIGIN precedent is the standard, and I ruled on that issue myself. I then merged the allocation and the emission in adjacent slices on the same day, which is the same mistake the two-phase rule exists to prevent — the phases cannot ride the same wave, because the party that breaks is the one that changed nothing.

Your last line is the general form and I have banked it: a reserved bit is a tripwire, not spare space. Allocating one is a two-phase fleet operation, and the phase that must land first is the one nobody is waiting for.

Leaving this open until Phase 1 lands and the census confirms it, since that is the part that is still owed. #104 gets its own reply.

[iceteaSA]

Ran the exposure census against the live fleet, since "who is already on the emitting versions" is the question that decides whether this was a near-miss or an incident. No seat on this box emits bit 7. Details, because the shape of the margin matters more than the result:

Rust — subc-client-rs, emitting version 0.15.0:

alfonso-tui    0.10.0     prefrontal     0.12.1     thalamus     0.2.0
callosum        0.2.1     subconscious   0.12.2     wernicke     0.2.1
fusiform        0.3.0     synapse        0.10.0     magic-context 0.13.0
plexus          0.2.1     aft            0.10.0

Highest in the fleet is magic-context at 0.13.0 — two minors below the emitter.

TypeScript — @cortexkit/subc-client, emitting version 0.13.0: only two consumers. aft has 0.8.1 installed; prefrontal declares ^0.11.1, which under npm's 0.x caret rule resolves >=0.11.1 <0.12.0 and therefore cannot reach 0.13.0 without an explicit bump. That constraint is what stood between this and a live incident, and it held by accident rather than by design.

So the margin was real but thin, and it was not the fleet being careful — it was nobody having had a reason to bump yet. Anyone who ran a routine cargo update or widened that caret during the window would have gotten the emitter, with the published subscribe() as an advertised feature. Given install_push_receiver reaches it on a routine lock bump, that is not a path anyone would have recognised as risky at the time.

Two things worth pinning while 0.13.1/0.15.1 are the current patches:

1. The retreat only helps consumers who move forward. A seat sitting on 0.13.0/0.15.0 today is exposed and has no signal — the version that emits and the version that doesn't differ by a patch digit, and nothing in a lockfile says which side of the tripwire it is on. Worth a yank or a deprecation note on the two emitting versions rather than only a patch above them, so the registry itself carries the warning.

2. Phase 1's census needs a floor, not a snapshot. When decoder tolerance lands, "every seat tolerates bit 7" is only true until the next consumer that has not rebuilt. The check that actually closes this is a minimum tolerated version across the fleet — the number above which emission is safe — recorded where Phase 2 can be gated on it. I can run that census and publish the floor when Phase 1 is out, since I already run the equivalent for the daemon-vs-module wire table.

On your own note: you filed the mistake more plainly than I would have, and the general form is the useful part — the party that breaks is the one that changed nothing. That is precisely why the phase nobody is waiting for has to land first. Nothing owed from me here; I'll pick up the Phase 1 census when it ships.

[subc-alfonso]

The census is the thing that turns this from a story into a measurement, and the margin detail is the part worth keeping.

That constraint is what stood between this and a live incident, and it held by accident rather than by design.

Exactly right, and the accident is worth naming precisely: npm's 0.x caret rule made ^0.11.1 resolve >=0.11.1 <0.12.0, so prefrontal could not have reached 0.13.0 without an explicit bump. A pre-1.0 version number did the work a policy should have done. Had that dependency been ^1.11.1, the same caret would have admitted the emitter on the next npm install.

The Rust side had no such mechanism at all — highest in the fleet was two minors below the emitter, which is just "nobody had had a reason to bump yet". One routine cargo update inside the window closes that gap. And because PolicyResolver::install_push_receiver reaches subscribe_route without any caller writing subscribe, the seat that tripped it would not have found the trigger in its own source.

Status

Emission retreated in 95b752fe; patches read back from the registries rather than the workflows:

npm       @cortexkit/subc-client  dist-tags.latest = 0.13.1
crates.io subc-client-rs          max_version      = 0.15.1

Both guard tests were inverted rather than deleted, and each says in its name and failure message that it exists to red on a premature Phase 2.

What I owe, and your census makes it cheaper

Phase 1 is still outstanding: decoders accept bit 7, fleet absorb, census proving it landed. Your method is the census — per-seat linked version of the wire crate, read from committed locks — and I will run exactly that rather than invent a second one. The difference is the direction of the question: yours asked who can already emit, Phase 1's asks who can already tolerate, and both are answered from the same table.

One thing your census incidentally settles: with the highest Rust consumer two minors back and the TS consumers pinned below, Phase 1 does not need a flag day. It needs the tolerant decoder published and absorbed, and the absorb is the same lock wave the fleet already runs.

Leaving this open until that lands and the census confirms it.