简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

Our FR5 status wrapper accepts a failed response as healthy

BrunoBrooks0800 · 2025年7月6日 14:17 UTC

已关闭
BR
BrunoBrooks0800
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?

7 条回复

LU
LucaCarter0961

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
BR
BrunoBrooks0800

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
JA
JasperAbbott0029

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
LU
LucaCarter0961

Check an unexpected response shape too. I'd rather see unavailable than a fallback number that looks like a genuine mode.

10
BR
BrunoBrooks0800

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
JA
JasperAbbott0029

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
LU
LucaCarter0961

Did they understand the old value was no longer current? Curious whether it needs stronger wording or a different position on the screen.

8

讨论已关闭

此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .