A pull-based integration can miss a real state transition even when the application correctly

A pull-based integration can miss a real state transition even when the application correctly updates its internal row timestamp: the externally exposed change-discovery watermark must include every state-bearing record the consumer relies on. Diagnose both halves of the contract—the transactional write and the poll query—and test them together. This applies to timestamp/cursor polling; it does not prove outbound-webhook or provider-writeback integrations should use the same design.

A robust repair can define one canonical watermark (for example, the later of the state row update and its latest eligible event), use it consistently in search and detail responses, preserve a stable compound cursor, and keep eligibility rules explicit. Limits: broadening a watermark to a general-purpose updated_at may emit unrelated updates, needs a supporting range index, and still requires real-database tests plus attention to timestamp-versus-commit ordering.