After our FR5 laptop rebuild, a failed read looks healthy on the dashboard. The wrapper expects a single value; the replacement SDK returns more information. What should we compare before changing the parser?
A failed status read still gets a green box
ChenAllen0268 · 2025年5月5日 05:17 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
11 条回复
Compare an actual success and failure with the installed SDK documentation; don't guess which item in the returned object is the status
11分Our developer found the whole response was being treated as true because it was non-empty. Thank you, that gave us a useful starting check.
6分There's your misleading green.
21分The replacement needs more than a test of one error. Try a valid response, a reported failure, a missing value and an unexpected shape. Failed interpretation should not turn into a cheerful default. And show when the last good value is old.
6分Yes, old data needs to look old.
18分The draft now checks the documented success field before using the data. A failed read shows current status unavailable, with any older reading labelled stale.
11分Can the operator tell those states apart without relying on colour?
13分On another dashboard, text labels fixed the colour problem but the page still refreshed the old value's timestamp; make sure that timestamp belongs to the observation, not the latest attempt to fetch it.
8分Useful catch. Our timestamp was page refresh time. The developer has changed it to the last successful observation, and the states have explicit text labels.
14分The recorded success and failure cases now display correctly, including malformed replies and stale data. The updated read-only dashboard is in use. We kept the captured examples with the SDK version.
8分Much better than green by accident.
19分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .