Eleven exits from one function, and the five that must not remember anything

The function responsible for processing search results has eleven potential exit points, but five of these must be handled carefully to ensure correct behavior. Writing to the snapshot, which serves as the app's memory of seen results, should never happen if the outcome is blocked, the listings array is null, authentication fails, there are no current listings, or there is a partial load with too many skipped entries.

These five scenarios each have distinct user-visible consequences and are not combined into a single branch. If the login wall path were to write the snapshot, a user logging in would result in no alerts, as new listings would be considered an entirely new page. This would lead to zero alerts rather than forty, as a result that is almost entirely new trips a separate guard.

The only exit that relinquishes control is for partial loads, where three consecutive checks agreeing indicate the page has stabilized. This prevents the search from becoming permanently stuck with an inaccurate baseline. The final exit, handling new listings, writes to the snapshot after the notification is sent. This ensures that failed sends don't record listings as seen, preventing them from being missed in future alerts.

An empty page is treated as a failure, as it could indicate various issues like classification failures, rendering problems, or genuinely no results. The trade-off is between false alarms and silently writing an empty baseline for working searches.