简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
LeoBaker0449 · 2025年11月14日 02:05 UTC
Select the parser from the supported interface version, then check success and required fields before using the status; don't let a nonempty container become your availability decision
12分That is exactly the current mistake. I have saved a failed reply and a successful one from each documented format, with the version beside them.
4分Keep the unsupported-version case in the test set as well. Otherwise somebody installs another environment later and your explicit two-format parser quietly becomes a guess again.
6分What would I actually see when it cannot interpret the answer? We had a display at our workshop that stayed cheerfully green while its little detail line admitted it had no new information. From where I stood, it was green. That was the entire message. I'm not arguing for deleting useful history, but I don't want the old reading doing the job of the current one just because the software has nowhere else to put it.
0分Hazel Archer's question is worth testing on the actual screen layout. An unavailable current reading and a dated historical reading can coexist, but they need visibly different roles. Don't rely on one tiny word to explain it.
19分The current draft blanks the live value and says unavailable. Previous valid reading is in details with its observation time. Nothing historical exists after an initial failure.
9分Leo, include missing fields and unexpected shapes too; a response can look successful enough to tempt the old parser without being valid for either supported format
7分Isabel, exactly. I would rather open details deliberately than squint at green and wonder which bit of the message I'm meant to believe.
22分Both format parsers pass the success, failure and malformed cases offline. The prior observation time was being refreshed on failure; that is now fixed in the draft too.
17分Which installed environment does the launcher use? Passing a test in one terminal is not enough if the classroom shortcut starts another package copy.
9分And keep those captured examples separate from deliberately malformed cases. The latter are useful tests, not evidence that the controller sent a reply of that shape.
25分Launcher path is recorded and uses the intended environment. Captures and constructed cases are separate. The installed screen check has not been completed yet.
20分Could a person unfamiliar with the rewrite try reading it? The developers already know which bit is old.
6分Yes, that is in the operator review. They will see current success, failure after success and initial failure without me explaining each screen first.
5分Include recovery after a valid reading returns; unavailable should not become a permanent display state either
23分Hazel Bell, agreed. The cheap test sequence is useful in both directions. It should also show that returning data carries its own new observation time, not the old one retained for history.
10分Screen review passed those transitions, and the read-only installed check matched the documented format. Unsupported-version deployment remains blocked by the new explicit check. I am keeping the alternate-format tests with the handover.
14分Who owns that test set after handover? The next environment change should trigger it without needing Leo to notice another suspiciously happy tile.
12分此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .