[beekld]

Summary

#489 reset the public DataSourceStatus.StateSince to the current time whenever a synchronizer started, even when State didn't change, and without broadcasting the new status. StateSince is documented as the time State most recently changed. An app that measures how long the SDK has been Interrupted had its clock reset on every failover, and status listeners held a different StateSince than GetStatus().

The reset existed so that each synchronizer gets its own fallback and recovery window. The data system now records when the current synchronizer started in a private field. The fallback and recovery conditions measure from the later of that time and StateSince, so their timing is unchanged. StateSince again changes only when State changes.

---

Note

Overview
DataSourceStatus.StateSince is no longer reset when a synchronizer starts. Starting a synchronizer used to call restartStatusClock(), which bumped StateSince even though State stayed the same (e.g. still Interrupted during failover), breaking apps that measure outage duration and leaving listeners out of sync with GetStatus().

The synchronizer loop now records syncStartedAt when each synchronizer starts. Fallback and recovery predicates still get a per-synchronizer window by evaluating conditionAction against the later of StateSince and syncStartedAt (local copy only—the stored status updates StateSince only when State changes in maybeUpdateStatus).

A regression test asserts that after primary failure and secondary start, StateSince is unchanged.

^{Reviewed by Cursor Bugbot for commit 3db133f. Bugbot is set up for automated code reviews on this repo. Configure here.}