Our dashboard for diagnostic status retrieval on Universal Robots UR5e 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 sample housing as a reference.
I'm trying to fix how we interpret the answer.
Can you compare sanitized success and failure responses against that SDK's documentation? The useful detail is which field your wrapper treats as status.
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.
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.
Fair point. Those two are a regression case, not full coverage. The adapter also needs documented error cases, transport exceptions and malformed responses exercised.
Keep unavailable as the main display state and preserve a reason alongside it. Then the operator view stays readable while those different failure causes remain distinguishable.
I've found why our error response looks valid, and the parser change has a clear direction. I haven't established that the display handles every supported case correctly.