A stale "checking..." restored from disk is a lie, so one of our six stores has no file

Notifio is a desktop application that monitors rental search pages on a user's machine. It maintains six pieces of state, each with its own rule regarding longevity. These rules were not intentionally planned, but rather emerged as the application encountered bad outcomes that users could observe. The sole purpose behind these rules is to determine what the state represents.

The six pieces of state are as follows:

1. Restart readiness

2. Searches being re-pointed

3. Email notifications

4. License configuration

5. JSON file in data directory

6. Recent finds

7. Ledger of replies

8. Live status per search run

The application displays the live state of each search, including whether it is currently being checked, the success of the last check, whether it was walled, the duration of the check, the number of listings on the page, and when the next check is due. Crucially, there is no file storing this information; it resides solely in memory.

The "one with no file" refers to the last entry in the table. While the monitor operates, each search has a live state associated with it. This state includes details such as whether the search is being checked, the outcome of the last check, whether it was walled, the duration of the check, the number of listings shown, and the time until the next check. None of these details are saved to a file; instead, they are stored in memory.

The reason for this design decision is that persisting the information as a file would make the application more complex and difficult to debug. By keeping this data in memory, the application avoids unnecessary file I/O and potential issues that could arise from storing stale or corrupted data.