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?
the ur5e wrapper guesses its way through both response formats
OmarBrooks0839 · 2026年1月11日 06:23 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
6 条回复
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分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分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分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分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分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分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .