Skip to content

Carry the seventh shape wire element, and stop faking a TCP offset - #49

Open
Jepson2k wants to merge 1 commit into
mainfrom
_fix/shape-physics-seventh
Open

Carry the seventh shape wire element, and stop faking a TCP offset#49
Jepson2k wants to merge 1 commit into
mainfrom
_fix/shape-physics-seventh

Conversation

@Jepson2k

@Jepson2k Jepson2k commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

Two changes that together let a downstream host move its waldoctl pin to
0.13.

ShapeWire was one field short. 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 pin moved. The two read
paths dropped physics 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 in both directions.

tcp_offset() faked an answer. It returned [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 RobotClient
docstring 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.

Tests: 280 passed, 8 skipped. The one failure,
test_msg_mounts_on_the_flange_not_inside_the_wrist, fails identically
with these changes stashed — pre-existing, not from this.

🤖 Generated with Claude Code

https://claude.ai/code/session_012tyAH93sLjc6W8Kp9ygFS8

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant