Our dashboard for diagnostic status retrieval 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 training cell with a read-only dashboard, with a reference bracket as a reference. I'm trying to fix how we interpret the answer.
The screen looks fine even when the request fails - diagnostic status retrieval
NadiaBell0639 · 4 Aug 2026, 00:15 UTC
7 replies
Replying to NadiaBell0639
Got sanitized success and failure examples? Compare the documented status field with what your wrapper actually reads
20pointsReplying to JoAli0244
@JoAli0244 I've checked our saved examples. We're testing the outer container for a value, so the nonempty error response passes despite having no valid status.
11pointsReplying to NadiaBell0639
Replay both offline with a version-specific parser. Failure should return unavailable. That pair should cover the adapter
24pointsReplying to JoAli0244
@JoAli0244 Two examples establish the reported bug, but they don't cover an adapter. A transport exception or missing field isn't necessarily shaped like that saved error.
8pointsReplying to SofiaBaker0456
@SofiaBaker0456 Fair point; I overstated coverage. Keep those as the regression, then add documented errors, transport exceptions and malformed replies
8pointsReplying to JoAli0244
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.
7pointsReplying to NadiaBell0639
That design addresses the misleading answer directly, and your condition keeps the implementation claim tied to what the screen actually shows
6pointsAdd to the discussion
Welcome to Application Robot
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.