aiolabs/spirekeeper
9
0
Fork 0
Code Issues 29 Pull requests Projects Releases Packages Wiki Activity Actions 2

feat(cassettes): persist the machine's counts-uncertain marker

Browse source 
The machine has been publishing counts_uncertain_since since v1 of the
state document and spirekeeper has been parsing it into a field nobody
read. That defeats the point of the marker: it exists so a human opens
the bay and recounts.

A dispenser can throw, or time out, after notes have physically moved.
The machine cannot know how many left, so rather than decrement a number
it would be guessing at, it stamps the moment (bitspire ADR-004,
decision 3). m014 gives that stamp a home on dca_machines, and the
consumer mirrors it on every state event.

Stored on the machine rather than the bay because the uncertainty is
about the dispense as a whole; a multi-bay dispense that fails midway
gives no reliable way to attribute it to one position.

Written through even when the machine reports None. The machine clearing
the marker is as important as setting it — the operator recounted, the
bay is trustworthy again — and a banner that never goes away is a banner
nobody reads.
This commit is contained in:
Padreug 2026-09-23 12:47:30 +02:00
commit c76a1bb125
5 changed files with 112 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

21
migrations.py
View file

@ -901,3 +901,24 @@ async def m013_add_cassette_ops(db):
"CREATE INDEX IF NOT EXISTS cassette_ops_machine_idx "
"ON cassette_ops (machine_id, created_at DESC)"
)
async def m014_add_counts_uncertain_since(db):
"""Surface the machine's "I don't know what left the bay" marker.
A dispenser can throw, or time out, after notes have physically moved. The
machine cannot know how many left, so rather than decrement a number it
would be guessing at, it stamps the moment and reports it (bitspire
ADR-004, decision 3). It has been publishing this field since v1 of the
state document and the operator has been discarding it, which defeats the
point: the marker exists to tell a human to open the bay and recount.
Stored on the machine, not the bay, because the uncertainty is about the
dispense as a whole — a multi-bay dispense that fails midway leaves no
reliable way to attribute it to one position. Cleared to NULL by the
machine's own report once it is confident again.
"""
await db.execute(
"ALTER TABLE spirekeeper.dca_machines "
"ADD COLUMN counts_uncertain_since TIMESTAMP"
)