Property RefuseWhenThermalUnknown
RefuseWhenThermalUnknown
Refuse to start a turn when EdgeResourceSnapshot.Thermal is
Unknown. Default false, and that is a decision rather
than an accident of enum ordering.
Sub-project 2 numbers Unknown = 0, below Nominal, and its own doc says "the
platform reports nothing usable. Never treat this as "fine"." A bare
state >= ThrottleAt would treat it as better than fine - never throttling, never
aborting - on every desktop, every hosted runner, and every Android device below API 29
where the thermal API is unavailable. So the comparisons in the decode loop are written
explicitly as thermal != Unknown && thermal >= threshold, with the intent
in the code rather than in the enum's numbering.
Having made it explicit, the default is still "do not refuse", for the same reason the
memory gate skips an unreadable AvailableMemoryBytes rather than refusing on it: a
reading nobody can make is never a refusal, and refusing here would make chat unusable on
every desktop. What sub-project 4 owes instead is visibility - Unknown is published
verbatim in the thermalState diagnostics key and in ChatTurnStatus.Thermal,
never normalised to Nominal - and this switch, for a caller who has measured their
hardware and wants the opposite.
ThrottleHeadroom gets the same treatment for free: Android returns
NaN when it is polled faster than about once a second or when the device does not
support it, and NaN >= 1.0f is false, so an unreadable headroom never
throttles. That is the same rule reached by a different route, and it is stated so nobody
"fixes" it.
public bool RefuseWhenThermalUnknown { get; set; }