The same entry after a retry
The offline timeclock needed to keep track of the same entry from the first tap on a device through to the network returning. Sending a clock-in twice should leave one entry. A later clock-out needs to find it even if the device has never received a response from the server.
The first LaborHounds implementation queued those actions, but review found that its retry method depended on a database index the operation could not use. Every queued clock-in would fail in the same way, leaving the clock-out behind it waiting. More retries could not repair that mismatch.
I chose the alternative recorded in the project history: generate the entry’s primary key on the device. The database already had a suitable primary-key index, so the repair needed no new migration. A repeated insert could refer to the same ID, and the device knew that ID from the first tap. The clock-out could use it too.
The ID change fixed that problem, but review found other recovery cases to address.
A reload exposed another gap. The page initially held its open-entry display in temporary application memory, so reloading could lose the display even though the clock-in was still waiting in the durable queue. The corrected version rebuilt that state from the queued entry and checked whose entry it was. An entry with a queued clock-out had to stay closed in the interface while the queue caught up.
A conflicting clock-in could represent time that still needed attention, and repeatedly retrying that same conflict could hold up the actions queued behind it. Silently deleting it would discard the record needed for recovery. The revised queue preserved the rejected action, including a dependent clock-out, and asked the page to reload the server’s state. A late clock-out could only update an entry that was still open.
I directed the product and made the choice between repair approaches; AI handled implementation and assisted with review. The commit and its regression cases cover duplicate punches, reloads and recovery paths. They live in the private LaborHounds repository, so this note is an account rather than a public artifact; I can walk through the commit and the cases on request. They do not establish field adoption or prove that every offline situation is handled.
