I need our dashboard to admit when it has no current reading. Since the environment change, the wrapper finds a number inside the SDK reply and shows it as status even when the request failed. The new reply has several fields. Where should the check live so the screen cannot make this mistake again?
FR5 status taken from the wrong part of the reply
RosaBrown0901 · 2026年4月7日 22:29 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
8 条回复
Put the response interpretation in one adapter tied to the SDK version you're using. Check the request outcome before extracting the documented status field. I would test it with saved replies first; no need to involve the whole cell to catch a parser choosing the wrong number.
15分The developer found the wrapper taking the first element it could turn into an integer. We have replaced that with the documented field lookup. A saved failed request now gives unavailable, not a status.
6分What does a good reading followed by that failure show?
17分And try a successful request with the status field absent. I caught a similar hole recently: the outer reply looked fine, then the wrapper supplied its own cheerful default.
1分Keep any previous reading visibly old, RosaBrown. The person checking the bench should not need to inspect the log to discover that the large status label is no longer current.
21分Both cases pass now. After failure the current field is unavailable; the last successful reading sits separately with its age. Missing status and unknown response shape also show unavailable. The maintainer tested startup, failure after success and recovery to a new success from the normal shortcut.
1分Thanks for checking recovery too. Has the export stopped presenting the retained value as current?
20分Yes. Export uses the same adapter result and identifies the retained reading separately. We compared the screen and exported rows through those cases after restarting the workstation. The maintainer has the restored environment and test examples; this one is closed.
9分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .