Carry the seventh shape wire element, and stop faking a TCP offset - #49
Open
Jepson2k wants to merge 1 commit into
Open
Carry the seventh shape wire element, and stop faking a TCP offset#49Jepson2k wants to merge 1 commit into
Jepson2k wants to merge 1 commit into
Conversation
waldoctl 0.13 adds `physics` to shapes, so `ShapeBase.to_wire()` returns SEVEN elements. `ShapeWire` declared six, and `set_shapes` builds one by positional unpack -- `ShapeWire(*s.to_wire())` -- so every call raised `TypeError: Extra positional arguments provided` the moment the waldoctl pin moved. The two read paths dropped `physics` on the floor for the same reason. `physics` is now a seventh field with a default, which keeps the struct readable both ways across that boundary: a peer still sending six decodes with `physics` absent, one sending seven decodes fully. Verified against waldoctl 0.13.1 -- 7-element encode, physics round-trips intact through `shape_from_wire`, a six-element peer still decodes, and msgspec agrees both directions. `tcp_offset()` also answered `[0, 0, 0]` when nothing replied. Zero is a legitimate offset -- a tool deliberately cleared -- so a caller handed it as a not-answered sentinel cannot tell "the offset is zero" from "there is no controller", and a host that adopts the readback quietly erases the offset the user just set. waldoctl's contract forbids exactly this. It raises `ConnectionError` now; `_request` already retries, so reaching that line means unreachable rather than one lost datagram. The waldoctl pin moves to v0.13.1 with them, since the shape fix is only meaningful there. Suite: 280 passed, 8 skipped. The one failure, `test_msg_mounts_on_the_flange_not_inside_the_wrist`, fails identically with these changes stashed -- it is pre-existing, not from this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012tyAH93sLjc6W8Kp9ygFS8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two changes that together let a downstream host move its waldoctl pin to
0.13.
ShapeWirewas one field short. waldoctl 0.13 addsphysicstoshapes, so
ShapeBase.to_wire()returns seven elements.ShapeWiredeclared six, and
set_shapesbuilds one by positional unpack —ShapeWire(*s.to_wire())— so every call raisedTypeError: Extra positional arguments providedthe moment the pin moved. The two readpaths dropped
physicsfor the same reason.physicsis now a seventh field with a default, which keeps the structreadable both ways across that boundary: a peer still sending six
decodes with
physicsabsent, one sending seven decodes fully.Verified against waldoctl 0.13.1: 7-element encode, physics round-trips
intact through
shape_from_wire, a six-element peer still decodes, andmsgspec agrees in both directions.
tcp_offset()faked an answer. It returned[0, 0, 0]when nothingreplied. Zero is a legitimate offset — a tool deliberately cleared — so a
caller handed it as a not-answered sentinel cannot tell "the offset is
zero" from "there is no controller", and a host that adopts the readback
quietly erases the offset the user just set. waldoctl's
RobotClientdocstring forbids exactly this. It raises
ConnectionErrornow;_requestalready retries, so reaching that line means unreachablerather than one lost datagram.
The waldoctl pin moves to v0.13.1 with them, since the shape fix is only
meaningful there.
Tests: 280 passed, 8 skipped. The one failure,
test_msg_mounts_on_the_flange_not_inside_the_wrist, fails identicallywith these changes stashed — pre-existing, not from this.
🤖 Generated with Claude Code
https://claude.ai/code/session_012tyAH93sLjc6W8Kp9ygFS8