The same entry after a retry
An offline timeclock has to hold a simple promise across an awkward gap: the entry someone starts on a device must still be the same entry when the network returns. 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. AI implemented the change. 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.
That fixed the identity problem. The review still had work to do.
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 preserved commit and regression cases document the work. They cover duplicate punches, reloads and recovery paths, without establishing field adoption or proving that every offline situation is handled.
