I want the failure shown honestly on our stores-side diagnostic screen. The newer SDK returns a container where our old wrapper expected a status value, and a failed read now looks plausible. I've asked the maintainer to compare the documented response formats, but what should we check on the screen as well?
Our FR5 status wrapper accepts a failed response as healthy
BrunoBrooks0800 · 2025年7月6日 14:17 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
7 条回复
Try a good read followed by a failure and watch the old value. It needs an obvious stale indication, not just an error tucked under a healthy-looking number.
17分The old value stays, and the page updates its time on every refresh. So even when it fails, the old reading gets a new-looking timestamp. Two problems for the maintainer.
7分Ask for the observation time separately from the refresh attempt; actually, label both if both are useful, because one unlabeled time is how we ended up reassuring ourselves with old data.
16分Check an unexpected response shape too. I'd rather see unavailable than a fallback number that looks like a genuine mode.
10分We have test cases for both documented versions, reported failure and malformed data. The revised screen shows the last valid observation time and a separate read failure. Still to be tried by the workshop users.
17分Let them explain what they'd do after the failure without prompting. That will tell you whether the wording helps or merely satisfies everyone who wrote it.
21分Did they understand the old value was no longer current? Curious whether it needs stronger wording or a different position on the screen.
8分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .