I'm fixing our controller status polling dashboard for Universal Robots UR5e in a workshop status-monitoring station. Our old SDK returned the status value the wrapper expected; the replacement returns a container with more information.
Failed requests can now look like plausible status readings. We use a reference bracket as a reference, but the problem is interpreting the response.
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.
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.
The nonempty-container check explains the misleading status. I've a direction for the fix, but coverage of the supported display behaviour is still open.