test: fix flaky image timestamp check on coarse clocks

TestImagesCreateUpdateDelete asserts that an image's updatedat is
strictly after its createdat. Both timestamps are stamped via
time.Now().UTC(), which strips the monotonic reading, so the comparison
falls back to the wall clock. On platforms with coarse timer resolution
(e.g. Windows, which advances system time at the ~15.6ms tick), the
Create and Update calls can land in the same tick and produce identical
timestamps, making the strict After() check fail intermittently.

Wait for the wall clock to advance past the creation timestamp before
updating so the assertion stays meaningful without depending on clock
resolution. On fine-resolution clocks the loop runs zero iterations.

Signed-off-by: Austin Vazquez <austin.vazquez@docker.com>
This commit is contained in:
Austin Vazquez
2026-06-12 14:02:42 -05:00
parent f546206f8d
commit e5e2190886

View File

@@ -563,6 +563,17 @@ func TestImagesCreateUpdateDelete(t *testing.T) {
checkImagesEqual(t, &created, &testcase.original, "unexpected image on creation")
// Wait for the wall clock to advance past the creation timestamp
// before updating. Create and Update both stamp time.Now().UTC()
// (which strips the monotonic reading), and on platforms with a
// coarse timer resolution (e.g. Windows) two back-to-back stamps
// can be identical, making updatedat == createdat. Spinning here
// keeps the strict "updatedat after createdat" assertion below
// meaningful without depending on clock resolution.
for !time.Now().After(created.UpdatedAt) {
time.Sleep(time.Millisecond)
}
// Update
now = time.Now()
updated, err := store.Update(ctx, testcase.input, testcase.fieldpaths...)