It has happened twice, to two accounts, and both times the only detector was a
person saying calls do not work. The second time it had stood for four days and
cost four wrong diagnoses on top, because the symptom coincided with an
unrelated change of the same day.
Nothing needs inventing. The daily group check from #0103 has the exact shape,
and it came from the same user for the same reason: signed in, silently broken,
noticed by complaint. What must not be trimmed from that template is written
into the issue — the wait loop against the policy race at pod start, and the
control that proves the query read anything at all, because zero affected
accounts and an empty database look identical otherwise.
The cause is ordinary operation rather than a fault: deactivating drops the row,
reactivating does not restore it.
Two corrections travel with it. The diagnostic shortcut from the first case, a
token count of zero, is stale and misled me today — it only catches accounts
that never placed a call, and this one had twenty-one, all old. And the AAR said
nine active accounts lacked a row while eight of them were deactivated, which
cannot both be true: nine lacked a row, eight were deactivated, one was not.
Thore Cimbal
14c0db7d7c