Skip to content

fix(test): de-flake date-dependent TestProbe_StaleWhenOnlyOldBackupServes#188

Merged
kuny0707 merged 2 commits into
tronprotocol:developfrom
barbatos2011:fix/probe-stale-test-date-flake
Jun 15, 2026
Merged

fix(test): de-flake date-dependent TestProbe_StaleWhenOnlyOldBackupServes#188
kuny0707 merged 2 commits into
tronprotocol:developfrom
barbatos2011:fix/probe-stale-test-date-flake

Conversation

@barbatos2011

Copy link
Copy Markdown

What

De-flake TestProbe_StaleWhenOnlyOldBackupServes in internal/snapshot/probe_test.go.

Why

The test is date-dependent and fails on a fraction of calendar days, reddening Test + coverage and e2e on develop and on every PR branched off it (currently visible on the open monitoring PR #185, whose failures are this test, not its own code).

It picked today − 45d and snapped backward to the nearest 10/20/30 day-of-month so the served backup would land in generateDateList's sparse tier (which, beyond 30 days back, emits only days 10/20/30). But when today − 45 falls on a day-of-month < 10, the backward snap loop (for d := day; d > 0; d--) finds no 10/20/30 day and falls through, leaving the served date on a day the probe never generates as a candidate. The probe then finds nothing and returns Unreachable, while the test asserts Stale.

Today's date triggers it: 2026-06-15 − 45 = 2026-05-01 → day 1 → no snap → 20260501 isn't a candidate → fail.

Fix

Serve a date in generateDateList's dense tier instead — today − 15d. Every day within the first 30 back is always emitted, so it's a probe candidate on any calendar day, and 15 > the 7-day stale threshold keeps it reliably Stale. No snapping, no date dependency.

Verified: passes across repeated runs; full TestProbe* group green; gofmt/vet clean. Test-only change.

…ndent)

The test picked today-45d and snapped backward to the nearest 10/20/30
day-of-month so the served date would land in generateDateList's sparse
tier. But when today-45 fell on a day-of-month < 10, the backward snap
loop found no 10/20/30 day and left the served date on a day the probe
never generates as a candidate — so the probe returned Unreachable and
the test wanted Stale. It failed on any run where today-45 < the 10th
(e.g. 2026-06-15 -> 2026-05-01, day 1), reddening CI on develop and
every PR branched off it.

Serve a date in the DENSE tier instead (today-15d): every day within the
first 30 back is always emitted, so it's a candidate on any calendar
day, and 15 > the 7-day stale threshold keeps it reliably Stale. Removes
the date dependency entirely; no snapping. Verified green across repeated
runs.
The equivalence gate failed with 'destination ... already has a
database; pass --force' (exit 10) whenever the weekly fixture cache key
rolled. actions/cache reports cache-hit='true' only on an EXACT key
match; the 'restore-keys: nile-fixture-' prefix fallback still restores
last week's fixture into ./nile-fixture but reports cache-hit=false. The
download step was gated 'if: cache-hit != true', so it re-ran into a
populated dir and snapshot download (correctly) refused to clobber.

Guard on whether the fixture DB directory actually exists instead of on
cache-hit: present (exact OR restore-keys hit) → use it; absent (cold
miss) → download + prune. Removes the step-level cache-hit gate. Any
restored snapshot is valid for equivalence since both Go and Java diff
the same copy.

Surfaced reviewing tronprotocol#188 (the probe de-flake); affects every PR touching
internal/snapshot/** or internal/dbfork/** on a week-key roll, including
the monitoring PR tronprotocol#185.
@kuny0707
kuny0707 merged commit cfc8ca4 into tronprotocol:develop Jun 15, 2026
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.

2 participants