the ur5e wrapper guesses its way through both response formats

OmarBrooks0839 · 11 Jan 2026, 06:23 UTC

Closed
OM
OmarBrooks0839
Our UR5e monitor handles a good read followed by failure now, but the compatibility wrapper still picks any plausible mode from an unfamiliar response container; how do we stop supporting every version by accident?

6 replies

CA
CallumAdams0099
Replying to OmarBrooks0839

Support an explicit set of documented interface versions, with a tested parser for each shape. Unknown versions or malformed responses should be unavailable, not a treasure hunt for a mode value.

22 points
OM
OmarBrooks0839
Replying to CallumAdams0099

Developer found the fallback behind it: if the expected field is absent, scan every value for something mode-like; removing that breaks one old fixture in our test suite, not the installed read

14 points
CA
CallumAdams0099
Replying to OmarBrooks0839

Identify what that old fixture represents before replacing it. It might be obsolete, or it might be your only example of a supported response the new parser forgot.

19 points
IS
IsaacAllen0346
Replying to OmarBrooks0839

And put the supported versions in the handover. Otherwise the next upgrade inherits a vague yes from the last person who saw the screen turn green.

-1 points
OM
OmarBrooks0839
Replying to CallumAdams0099

Old fixture was invented for the mock and matches neither supported format; replaced with documented success and failure examples, then tested malformed containers, unknown versions and success followed by failure without the guessing fallback

14 points
OM
OmarBrooks0839
Replying to IsaacAllen0346

Maintainer's installed read-only comparison matches the expected mode and source version, and the failure display stays unavailable rather than borrowing a value; supported-version note is in the handover, Isaac, so I'm closing this wrapper fix

9 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .