Skip to content

Commit cfc8ca4

Browse files
authored
Merge pull request #188 from barbatos2011/fix/probe-stale-test-date-flake
fix(test): de-flake date-dependent TestProbe_StaleWhenOnlyOldBackupServes
2 parents facb463 + 2dcde08 commit cfc8ca4

2 files changed

Lines changed: 56 additions & 41 deletions

File tree

.github/workflows/dbfork-equivalence.yml

Lines changed: 44 additions & 29 deletions
Original file line numberDiff line numberDiff line change
@@ -141,38 +141,53 @@ jobs:
141141
restore-keys: |
142142
nile-fixture-
143143
144-
- name: Build trond + download Nile fixture (if cache miss)
145-
if: steps.fixture-cache.outputs.cache-hit != 'true'
144+
- name: Build trond + download Nile fixture (if absent)
145+
# Guard on whether the fixture is actually PRESENT, not on
146+
# cache-hit. actions/cache sets cache-hit='true' only on an EXACT
147+
# key match; a `restore-keys: nile-fixture-` prefix fallback (the
148+
# common case when the weekly key rolls) still restores last
149+
# week's fixture into ./nile-fixture but reports cache-hit=false.
150+
# The old `if: cache-hit != 'true'` then re-ran the download into
151+
# a dir that already had a database, and `snapshot download`
152+
# (correctly) refuses to clobber without --force → exit 10
153+
# HUMAN_REQUIRED. Any restored snapshot is fine for equivalence
154+
# (both Go and Java diff the same copy), so: present → use it;
155+
# absent → cold download + prune.
146156
run: |
147157
set -euo pipefail
148-
go build -o bin/trond ./
149-
./bin/trond snapshot download \
150-
--network nile --type lite \
151-
--to ./nile-fixture
152-
# snapshot download streams gunzip|tar straight to disk and
153-
# never persists the .tgz, so there is nothing to clean up
154-
# here. Guard that the extracted layout the test expects
155-
# actually materialised, so a future download-format change
156-
# fails here instead of as a confusing SKIP downstream.
157158
DB=./nile-fixture/output-directory/database
158-
test -d "$DB" \
159-
|| { echo "::error::fixture missing output-directory/database after download"; exit 1; }
160-
# Prune to the 8 dbfork stores. A full Nile snapshot is ~90 GB,
161-
# dominated by block/trans/pbft-sign-data which dbfork never
162-
# touches — java DbFork's initStore() and Go's Apply open only
163-
# these 8 stores. The test makes TWO scratch copies, so keeping
164-
# the bulk overflowed the runner disk ("no space left on
165-
# device"). Pruning frees ~40+ GB and is what gets cached, so
166-
# cache-hit runs are already lean.
167-
KEEP="witness witness_schedule account properties asset-issue-v2 account-asset contract storage-row"
168-
for d in "$DB"/*/; do
169-
name=$(basename "$d")
170-
case " $KEEP " in
171-
*" $name "*) : ;; # keep the 8 dbfork stores
172-
*) rm -rf "$d" ;; # drop everything else
173-
esac
174-
done
175-
echo "Pruned fixture to dbfork stores; remaining:"
159+
if [ -d "$DB" ]; then
160+
echo "Fixture already present (exact or restore-keys cache hit); skipping download + prune."
161+
else
162+
go build -o bin/trond ./
163+
./bin/trond snapshot download \
164+
--network nile --type lite \
165+
--to ./nile-fixture
166+
# snapshot download streams gunzip|tar straight to disk and
167+
# never persists the .tgz, so there is nothing to clean up
168+
# here. Guard that the extracted layout the test expects
169+
# actually materialised, so a future download-format change
170+
# fails here instead of as a confusing SKIP downstream.
171+
test -d "$DB" \
172+
|| { echo "::error::fixture missing output-directory/database after download"; exit 1; }
173+
# Prune to the 8 dbfork stores. A full Nile snapshot is ~90 GB,
174+
# dominated by block/trans/pbft-sign-data which dbfork never
175+
# touches — java DbFork's initStore() and Go's Apply open only
176+
# these 8 stores. The test makes TWO scratch copies, so keeping
177+
# the bulk overflowed the runner disk ("no space left on
178+
# device"). Pruning frees ~40+ GB and is what gets cached, so
179+
# the restored fixture on later runs is already lean.
180+
KEEP="witness witness_schedule account properties asset-issue-v2 account-asset contract storage-row"
181+
for d in "$DB"/*/; do
182+
name=$(basename "$d")
183+
case " $KEEP " in
184+
*" $name "*) : ;; # keep the 8 dbfork stores
185+
*) rm -rf "$d" ;; # drop everything else
186+
esac
187+
done
188+
echo "Pruned fixture to dbfork stores."
189+
fi
190+
echo "Fixture stores:"
176191
ls -1 "$DB"
177192
df -h . | tail -1
178193

internal/snapshot/probe_test.go

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -59,18 +59,18 @@ func TestProbe_OKWhenRecentBackupServes(t *testing.T) {
5959
}
6060

6161
func TestProbe_StaleWhenOnlyOldBackupServes(t *testing.T) {
62-
// A backup older than the staleness threshold but still inside the
63-
// generated date list. 35 days back is in the "10/20/30" tier of
64-
// generateDateList. To guarantee it lands on a 10/20/30 day, pick a
65-
// fixed-but-rolling target.
66-
old := time.Now().UTC().AddDate(0, 0, -45)
67-
// Snap to the nearest 10/20/30 of that month, going backwards.
68-
for d := old.Day(); d > 0; d-- {
69-
if d == 10 || d == 20 || d == 30 {
70-
old = time.Date(old.Year(), old.Month(), d, 0, 0, 0, 0, time.UTC)
71-
break
72-
}
73-
}
62+
// Serve a backup that is older than the 7-day staleness threshold but
63+
// still inside generateDateList's DENSE tier — every day within the
64+
// first 30 days back is emitted, so a date 15 days back is always a
65+
// probe candidate regardless of which calendar day the test runs on,
66+
// and 15 > 7 makes it reliably stale.
67+
//
68+
// The previous logic ("45 days back, snapped backward to the nearest
69+
// 10/20/30 day-of-month") was date-dependent and flaked: when
70+
// today-45 landed on a day-of-month < 10 the backward snap found no
71+
// 10/20/30 day, left the served date on a day generateDateList never
72+
// emits, and the probe returned Unreachable instead of Stale.
73+
old := time.Now().UTC().AddDate(0, 0, -15)
7474
oldStr := old.Format("20060102")
7575
src := buildProbeMirror(t, oldStr)
7676

0 commit comments

Comments
 (0)