Two devices push to each other forever when a save returns to an earlier state (since #42) #71

Summary: since #42, two devices can end up both pushing to each other forever, so a change never arrives. This is what makes TestReportedWAN_AlternatingEditsMustNotConflict fail on Windows CI ("round N: B's edit never reached A"): about 1 in 15 runs on my fork, both on dev-public and with #51. It also failed on dev-public in run #337 and on #55 in run #347.

What happens (from the daemons' logs, captured with #57):

1. A save returns to bytes identical to an earlier state. The test writes the same "a-turn" / "b-turn" every round; in real use, a setting toggled back can do the same.
2. One device's base is still a round behind, for example while the report of the other's pull hasn't been processed. A's base is then the previous "b-turn".
3. B writes "b-turn" again, which hashes identical to A's stale base. With fix(sync): prefer agreed base over misleading file mtimes #42's rule (remoteHash == baseHash && localHash != baseHash → push), A concludes B hasn't changed and pushes. B correctly sees itself as newer and pushes too.
4. Neither pulls, so nothing moves A's base, and they trigger each other several times a second until the test gives up:

B: local has newer content; triggering "WanAlternate-A" to pull
A: WAN API request: GET /sync/trigger/wanalternate from B
A: local has newer content; triggering "WanAlternate-B" to pull
B: WAN API request: GET /sync/trigger/wanalternate from A
... (repeating)

Deterministic reproduction of the decision (ComputeWithBase, one file slot1.sav, the lineage holding it):

• A: local "a-turn", remote "b-turn" (newer mtime), base = hash of the earlier "b-turn" → push
• B: local "b-turn", remote "a-turn", base = hash of "a-turn" → push

With #42 both push; on the commit before #42, A pulls and B pushes, which is correct. I can add this as a test with the fix.

The rule itself is sound: a side whose whole manifest equals the agreed base hasn't changed, except when the same bytes come back after the base was agreed (ABA). Hashes can't tell the two apart, and mtimes can't either: #42 exists precisely because a restored or touched copy of the base has a newer mtime, so a time-based guard would bring that bug back. As I see it, the options are:

• Make the base current sooner. sync: a peer that pulled says what it now holds, so the base is recorded at once #51 has the puller report what it now holds right after a pull, which narrows the window; it doesn't remove it (the test still fails with sync: a peer that pulled says what it now holds, so the base is recorded at once #51).
• Break the loop instead of the rule. A device that a peer has just told to pull, and which decides to push back to that same peer without either side having changed since, could treat the pair as diverged and ask, rather than push again. Nothing is overwritten, and the endless loop becomes one question.
• Versions instead of hashes (Proposal: decide syncs by save versions instead of guessing from files #29) remove the ambiguity at the root.

This is your design (cc @Seagulls), so I'd rather ask before changing it: which would you prefer? I'm happy to do the second as a PR with the reproduction as its test.

🤖 Generated with Claude Code