cultmesh-rs: RUDP document server refuses unreadable frames and deletes with typed errors #42

Merged
libby merged 1 commit from libby/rs-rudp-typed-refusals into main 2026-11-08 09:33:42 +00:00
Member

cultmesh-rs RUDP document server: two silent drops now answer with the typed refusals TS and Python send.

  • An undecodable schema frame (was continue) is refused message_invalid, details.field = "message", fixed reason "the message could not be read"; decoder text stays with the caller (MessageUnreadable).
  • A DocumentDelete (was _ => {}) is refused write_not_authorized naming the record, fixed reason "the server does not take deletes" (DeleteNotSupported).
  • Both end the peer's session like the existing refusals. The sink-refusal path (typed write_not_authorized) is unchanged; the server has no write-authority gate, and no write that was applied before is refused now or the reverse.
  • Bytes: unit test pins message_invalid_message against the shared error-vectors.json message_invalid vector (the write_not_authorized vector was already pinned).
  • Tests: new integration test; three hand mutants (field name, delete record key dropped, delete refusal text changed) fail it; a fourth (silencing the unreadable arm) does not compile, run under prlimit as=4GiB cpu=300. Full cultmesh-rs cargo test -j1 under ulimit -v 8GB passes.
  • Behaviour change: an unreadable frame used to be skipped and the session lived; it now ends that peer's session, like the other refusals.
  • Public enums gain variants (Operation::{DocumentDelete, Unreadable}, two reasons).

🤖 Generated with Claude Code

cultmesh-rs RUDP document server: two silent drops now answer with the typed refusals TS and Python send. - An undecodable schema frame (was `continue`) is refused `message_invalid`, `details.field = "message"`, fixed reason "the message could not be read"; decoder text stays with the caller (`MessageUnreadable`). - A `DocumentDelete` (was `_ => {}`) is refused `write_not_authorized` naming the record, fixed reason "the server does not take deletes" (`DeleteNotSupported`). - Both end the peer's session like the existing refusals. The sink-refusal path (typed `write_not_authorized`) is unchanged; the server has no write-authority gate, and no write that was applied before is refused now or the reverse. - Bytes: unit test pins `message_invalid_message` against the shared error-vectors.json `message_invalid` vector (the `write_not_authorized` vector was already pinned). - Tests: new integration test; three hand mutants (field name, delete record key dropped, delete refusal text changed) fail it; a fourth (silencing the unreadable arm) does not compile, run under prlimit as=4GiB cpu=300. Full cultmesh-rs `cargo test -j1` under ulimit -v 8GB passes. - Behaviour change: an unreadable frame used to be skipped and the session lived; it now ends that peer's session, like the other refusals. - Public enums gain variants (`Operation::{DocumentDelete, Unreadable}`, two reasons). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
cultmesh-rs: RUDP document server refuses unreadable frames and deletes with typed errors
Some checks failed
CultMesh QUIC native / Build win32-x64 (pull_request) Has been skipped
CultMesh QUIC native / Build linux-x64 (pull_request) Has been skipped
CultMesh QUIC native / Release native binaries (pull_request) Has been skipped
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Failing after 5m40s
CultMesh QUIC native / Verify committed binaries match SHA256SUMS (pull_request) Successful in 32s
34be64789e
An undecodable schema frame was dropped and a DocumentDelete ignored, both
silently. Now the first is refused message_invalid (details.field "message")
and the second write_not_authorized naming the record, each with a fixed
reason, ending the peer's session as the other refusals do. The sink gate is
unchanged. Both bytes are pinned against the shared error-vectors.json.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
libby merged commit fb705cbc1d into main 2026-11-08 09:33:42 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
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
GameCult/CultLib!42
No description provided.