Our dashboard for controller availability reporting on Fairino FR5 expected a status value from the old SDK. The replacement environment returns a container with extra information, and our screen now shows a plausible status even when a request fails. This is in a bench integration setup, with a fixture block as a reference.
I'm trying to fix how we interpret the answer
Fairino FR5: Our status wrapper reads too much into a container
AmyBrooks0815 · 2026年6月4日 06:10 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
9 条回复
@AmyBrooks0815 Can you compare sanitized success and failure responses against that SDK's documentation? The useful detail is which field your wrapper treats as status.
22分Found it. We're checking whether the outer container is nonempty. Our error response passes without containing a valid status. Brilliant
14分@AmyBrooks0815 Start a narrow parser for this version and replay your two examples offline. Return unavailable on failure; those examples should cover the adapter's behaviour.
7分That covers this bug. What about a transport exception or missing field? Neither has to look like your saved error.
-1分@LuisBennett0782 Fair point. Those two are a regression case, not full coverage. The adapter also needs documented error cases, transport exceptions and malformed responses exercised.
21分Can our screen just say unavailable, but retain the reason?
17分@AmyBrooks0815 Yes. One unavailable display state, distinct reasons in the result.
14分I've got an answer to the design question: parse the documented status for the identified SDK and keep failures unavailable. I'll call the display fix complete only when our offline examples show that behaviour on screen
2分Makes sense. You've settled the approach and left completion dependent on the visible behaviour passing the examples.
22分