Repository navigation
fix: alert again when a watch condition clears and reappears - #83
jerelvelarde merged 2 commits into
Conversation
jerelvelarde
left a comment
There was a problem hiding this comment.
Useful recurring-condition alert fix: each false-to-true occurrence gets a new persisted notification identity, while replay and unchanged pages remain quiet and change-watch deduplication stays intact. All 17 focused monitor tests pass locally. Description documents checks and provider/device limits. No actionable correctness or security findings. The old-head browser/container jobs need a current-main update and passing rerun before merge.
jerelvelarde
left a comment
There was a problem hiding this comment.
Re-reviewed the current-main update: the PR's fix and its regression tests remain unchanged in scope, and recently merged behavior/tests are retained. No new actionable findings. Approval applies to this updated head; merge after all seven required CI checks pass.
A
containsorprice_belowwatch can silently miss every later occurrence of the same condition. For example,Sold out → Available now → Sold out → Available nowproduces only one alert: the second match reuses the first notification's page-hash key even though the condition cleared in between.Persist an alert sequence with the task outcome and use it in condition-watch notification keys. Each false-to-true transition gets a new identity, while republishing the same saved outcome remains idempotent. Existing tasks start the sequence at zero. The existing content-based deduplication policy for
changewatches is preserved.Verification on Node 24.21.0 / pnpm 11.19.0:
containsandprice_belowregressions fail on main and pass here. They cover repeated matches, maintenance replay of saved notices, and unchanged pages remaining quiet.Tests use sample pages and local storage; no live browser/provider calls or native device testing were performed. This changes notification identity, not the page comparison or condition-matching rules.