简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
HanaBrooks0796 · 2026年6月16日 22:15 UTC
What exactly came back on failure, and how did your code turn it into availability? I wouldn't infer success from a nonempty container, but I'd like to see the actual mistake before prescribing a decoder.
21分The adapter tests whether the whole returned object is truthy. A failure response is still a nonempty object, so it becomes available. It never checks the documented result field.
3分Then available currently means something was returned, not that the read succeeded.
9分I would keep the last successful reading separate from the current request state. We had a screen that retained a useful old value but made it look current, which was a different error from decoding the reply wrongly.
-10分Rebecca, how could the reader tell it was old? A timestamp alone can look like a refresh time if the label does not explain what happened then.
18分They could not reliably tell in the first version. The time was present but poorly named, so I would test the meaning with a reader rather than assume adding digits fixes the problem.
18分For the decoder, use examples tied to the installed SDK version and check its documented success condition before interpreting the payload. Unknown shapes should be explicit failures of interpretation, not another route to available.
21分And before the first successful read? There is no old availability to preserve then.
1分Our draft now starts with no current reading. Failed requests show unavailable, and any previous good value is labelled separately with its successful-read time. The adapter changes are in offline checks only.
2分Does unavailable describe the controller itself or the ability to obtain a current reading? Those are different claims for the person deciding whom to call.
11分The current reading, not proven controller unavailability. Good catch, Theo. I have changed the wording to current reading unavailable so a communication failure isn't presented as a controller diagnosis.
4分Keep that distinction in any exported report as well. A careful screen and an overconfident CSV can still hand the next person the wrong conclusion.
19分Hana, have you tried a successful reply followed by an unfamiliar one? That sequence would show whether an interpretation error accidentally leaves the old current-state label visible.
-2分That offline sequence now marks the current reading unavailable and preserves the old value as historical. Unknown method calls fail too. Reconnect and slow-response behaviour still need tests.
19分Will a delayed reply be labelled with when it was read, rather than when the screen painted it?
20分Not settled yet. I've added that to the slow-response case rather than treating the new timestamp label as complete.
3分Then your decoder has improved under the tested cases, while freshness handling remains unfinished. I would keep those two statements together in the handover instead of marking the dashboard fixed.
7分