protocol: keep session order and daemon identity on one authority #343

Merged

natsukium merged 2 commits from issue-333 into main 2026-09-22 11:34:28 +09:00

Conversation 0 Commits 2 Files changed 31 +231 -208

natsukium commented 2026-09-22 10:27:20 +09:00

Owner

Copy link

Closes #333

No public operation can produce protocol_mismatch: it named a
wire-generation mismatch the preface refuses before a verb runs, so the
token sat in the machine vocabulary with a #[allow(dead_code)] and no
call site. The comment beside it called the token frozen in v1, but
that freeze is against a consumer that cannot exist yet — v1 is
unreleased and no producer exists in the workspace — so removing it now
is the same pre-release break the proto batch makes, not a v bump.

A token for this class comes back under the normal additive
machine-output policy once a public operation can raise one.

Refs #333.

A public 1.0 daemon always stamps a creation sequence, so the optional
SessionInfo.sequence and the id-order fallback it fed only described a
daemon that predates the field — a peer no released build can be. Making
the field required puts one order under the switch ring: 0, which is
also what an omitted field writes, is refused at decode instead of
quietly demoting a row.

OpsStatusReply repeated the build string and the wire pair that
Welcome.identity and the preface's accept already establish on every
connection, which left a client with two authorities for one fact and no
rule for which to believe. The connector now keeps the accepted major
and the daemon's own minor (not the effective minor: against a newer
daemon the two differ, and the report is about the daemon) and composes
DaemonStatus from the handshake plus the live reply, so
felis daemon status fills the same JSON keys from the same numbers and
its output is unchanged in both formats.

Rejected: keeping the copy so one message carries the whole report. The
reply is read on a connection whose handshake the same client conducted,
so the copy can name nothing the client does not already hold.

The unknown-mode second decode in serve.rs stays and is recorded as
what it is: a diagnostic that recovers the raw enum number for a peer
not honoring the send-side contract, not a compatibility fallback. A
conforming client refuses a mode above the effective minor before
Hello, so ordinary skew never reaches that path.

Refs #333.

Review

pi luna and sol reviews both passed. Non-blocking findings folded: the "optional fields" explanation no longer lists sequence, the pool comment and session-lifecycle rationale drop the absent-sequence wording, from_halves states that it models same-build peers, and the daemon-ahead connector test asserts daemon_minor. Cascade after rebasing onto #341/#342: the felis-json v1 session row's sequence is required (schema regenerated).

just proto-compat, fmt-check, prose-check, clippy --all-features and the Windows cross clippy pass locally; the workspace test run shows only the pre-existing socket-path-length failures on this machine. The Criterion regression gate is a known-flaky bench job and fails on every PR.

Closes #333 No public operation can produce `protocol_mismatch`: it named a wire-generation mismatch the preface refuses before a verb runs, so the token sat in the machine vocabulary with a `#[allow(dead_code)]` and no call site. The comment beside it called the token frozen in `v1`, but that freeze is against a consumer that cannot exist yet — `v1` is unreleased and no producer exists in the workspace — so removing it now is the same pre-release break the proto batch makes, not a `v` bump. A token for this class comes back under the normal additive machine-output policy once a public operation can raise one. Refs #333. A public 1.0 daemon always stamps a creation sequence, so the optional `SessionInfo.sequence` and the id-order fallback it fed only described a daemon that predates the field — a peer no released build can be. Making the field required puts one order under the switch ring: `0`, which is also what an omitted field writes, is refused at decode instead of quietly demoting a row. `OpsStatusReply` repeated the build string and the wire pair that `Welcome.identity` and the preface's accept already establish on every connection, which left a client with two authorities for one fact and no rule for which to believe. The connector now keeps the accepted major and the daemon's own minor (not the effective minor: against a newer daemon the two differ, and the report is about the daemon) and composes `DaemonStatus` from the handshake plus the live reply, so `felis daemon status` fills the same JSON keys from the same numbers and its output is unchanged in both formats. Rejected: keeping the copy so one message carries the whole report. The reply is read on a connection whose handshake the same client conducted, so the copy can name nothing the client does not already hold. The unknown-mode second decode in `serve.rs` stays and is recorded as what it is: a diagnostic that recovers the raw enum number for a peer not honoring the send-side contract, not a compatibility fallback. A conforming client refuses a mode above the effective minor before `Hello`, so ordinary skew never reaches that path. Refs #333. ## Review pi luna and sol reviews both passed. Non-blocking findings folded: the "optional fields" explanation no longer lists `sequence`, the pool comment and session-lifecycle rationale drop the absent-sequence wording, `from_halves` states that it models same-build peers, and the daemon-ahead connector test asserts `daemon_minor`. Cascade after rebasing onto #341/#342: the `felis-json` v1 session row's `sequence` is required (schema regenerated). `just proto-compat`, fmt-check, prose-check, clippy `--all-features` and the Windows cross clippy pass locally; the workspace test run shows only the pre-existing socket-path-length failures on this machine. The Criterion regression gate is a known-flaky bench job and fails on every PR.

natsukium added 2 commits 2026-09-22 10:27:20 +09:00

protocol: keep session order and daemon identity on one authority ... 9427979f11

A public 1.0 daemon always stamps a creation sequence, so the optional
`SessionInfo.sequence` and the id-order fallback it fed only described a
daemon that predates the field — a peer no released build can be. Making
the field required puts one order under the switch ring: `0`, which is
also what an omitted field writes, is refused at decode instead of
quietly demoting a row.

`OpsStatusReply` repeated the build string and the wire pair that
`Welcome.identity` and the preface's accept already establish on every
connection, which left a client with two authorities for one fact and no
rule for which to believe. The connector now keeps the accepted major
and the daemon's own minor (not the effective minor: against a newer
daemon the two differ, and the report is about the daemon) and composes
`DaemonStatus` from the handshake plus the live reply, so
`felis daemon status` fills the same JSON keys from the same numbers and
its output is unchanged in both formats.

Rejected: keeping the copy so one message carries the whole report. The
reply is read on a connection whose handshake the same client conducted,
so the copy can name nothing the client does not already hold.

The unknown-mode second decode in `serve.rs` stays and is recorded as
what it is: a diagnostic that recovers the raw enum number for a peer
not honoring the send-side contract, not a compatibility fallback. A
conforming client refuses a mode above the effective minor before
`Hello`, so ordinary skew never reaches that path.

Refs #333.

Assisted-by: Claude Code

cli: drop the protocol_mismatch error token ... 93d2518ac2

No public operation can produce `protocol_mismatch`: it named a
wire-generation mismatch the preface refuses before a verb runs, so the
token sat in the machine vocabulary with a `#[allow(dead_code)]` and no
call site. The comment beside it called the token frozen in `v1`, but
that freeze is against a consumer that cannot exist yet — `v1` is
unreleased and no producer exists in the workspace — so removing it now
is the same pre-release break the proto batch makes, not a `v` bump.

A token for this class comes back under the normal additive
machine-output policy once a public operation can raise one.

Refs #333.

Assisted-by: Claude Code

natsukium merged commit 6da5620d3b into main 2026-09-22 11:34:28 +09:00

natsukium deleted branch issue-333 2026-09-22 11:34:28 +09:00

natsukium referenced this pull request from a commit 2026-09-22 11:34:30 +09:00

protocol: keep session order and daemon identity on one authority (#343)

natsukium referenced this pull request 2026-09-22 14:37:30 +09:00

[v0.1/P1] Final interface simplification audit before public freeze #326

natsukium referenced this pull request 2026-09-22 19:18:55 +09:00

protocol, cli: pre-release review of frozen surfaces — six cheap-before-freeze gaps #347

natsukium referenced this pull request 2026-09-22 20:37:47 +09:00

protocol: post-freeze observability and descriptor completeness (effective minor, field-level since, bit tables) #351

Commenting is not possible because the repository is archived.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!343

No description provided.