Skip to content

Late-report test: edit after the clock-skew allowance; stamp a report's sync time when the comparison began - #63

Merged
Omar-VF merged 2 commits into
Liquid-co:dev-publicfrom
ChakraFusion:pr/late-report-test
Oct 15, 2026
Merged

Omar-VF merged 2 commits into
Liquid-co:dev-publicfrom
ChakraFusion:pr/late-report-test

Conversation

@ChakraFusion

Copy link
Copy Markdown

Two commits, for the TestMultiRootScenario_ALateReportDoesNotHideADivergence flake (see my note on #57).

  1. The cause (test only): with no merge base, edits within DetectConflict's 2 s clock-skew allowance after the last-synced stamp count as unchanged. The setup's own reports can stamp that time after SettleSync returns, and the test then edited 1.8–2.06 s after it. A 1.5 s gap fails every time; 3 s passes every time. The test now waits until the stamp is more than 3 s in the past. On Windows: 12 failures in 232 runs before, 0 in 435 after.
  2. Hardening, not the cause: RefreshLineage stamped "last synced" after reading both sides; it now uses the time the comparison began. TestRefreshLineage_StampsWhenTheComparisonBegan fails without it. Happy to split it into its own PR if you prefer.

The 2-second tolerance itself is the open question on #57.

🤖 Generated with Claude Code

ChakraFusion and others added 2 commits October 15, 2026 12:21
RefreshLineage, run when a peer reports it finished pulling or that the two
are in sync, stamped "last synced" once it had read both sides and written
the lineage. A location with no merge base yet counts only edits made after
that stamp (plus the 2 s clock-skew allowance) as new, so an edit made while
the refresh ran - seconds on a slow disk - could count as made before the
devices were compared.

The stamp is now the time the comparison began, before either side was
read. A stamp that ends up earlier than another written meanwhile only
makes more edits count as new, which is the safe direction.

Hardening, not the cause of the CI failure of
TestMultiRootScenario_ALateReportDoesNotHideADivergence: that was the test
editing inside the skew allowance, fixed in the next commit.

TestRefreshLineage_StampsWhenTheComparisonBegan: fails 3/3 without this
(stamp ~100 ms after the peer's side was read), passes with it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TestMultiRootScenario_ALateReportDoesNotHideADivergence clears the
location's merge base and has both devices edit it. With no base, edits are
judged against when the two were last confirmed the same, and only one made
more than DetectConflict's 2 s clock-skew allowance after it counts as new.
The refresh started by the setup's own reports can stamp that time after
SettleSync returns, and the edits then came within it: neither side read as
changed, B's version replaced A's, and the test reported "no conflict was
raised: A=\"B-version\" B=\"B-version\"" - on Windows CI about one shard
run in ten. Instrumented runs show the stamp 1.7-1.9 s before the edits
each time; a stamp 1.5 s before them reproduces the failure every time, and
3 s does not.

The test now waits until that time has stopped moving and is more than the
allowance in the past. It still fails as it should when a report stamps the
two as synced while the location differs (the bug it was written for).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@vercel

vercel Bot commented Oct 15, 2026

Copy link
Copy Markdown

@claude is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

@Omar-VF
Omar-VF merged commit e4a9fe8 into Liquid-co:dev-public Oct 15, 2026
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants