Our old SDK gave the dashboard a mode value. The rebuilt environment returns a container with extra information, and a failed request still produces a plausible mode on screen. I want the read-only reporting fixed before anyone trusts that answer. What should the adapter preserve instead?
Start with the documented return contract for the imported version and one saved failure, then show which field or fallback produces the displayed mode; a plausible number is not evidence of a successful read
Found the fallback. When the new container isn't decoded, we keep the previous mode and stamp it with the current polling time. The failure information never reaches the screen, so yesterday's answer can look freshly observed.
Maya's display distinction needs the adapter to expose success, failure and any valid payload separately, with no guessed mode for unsupported response shapes; otherwise the UI cannot know which case it has
The developer has mapped the supported response for each installed version explicitly. Unknown shapes return a decoding failure. The screen now distinguishes a current mode from a dated last observation, and startup has no mode until a successful read.
Include reopening with saved history as well, Will; the time must remain the observation's time rather than becoming the moment the dashboard happened to load it
Both sequences pass now, Maya and Sara. Saved failures, malformed responses and valid modes take their documented paths in both environments. The normal read-only check against the intended controller also passed, including unavailable-state display and reopening without a fresh read. The old timestamp-refresh fallback is gone.