Zhengchao An cf142e7fdd fix(ci): widen Days=5 expiration poll window to 8*lc_interval (#4779) ...

Follow-up to #4772. After forcing every-cycle ILM evaluation the Days=1
plateau is reliable, but test_lifecycle_expiration / test_lifecyclev2_expiration
still flaked intermittently on the *second* assertion (`assert 4 == 2`):
the Days=5 (expire3) objects were not expired within their poll window.

Cause: _wait_for_lifecycle_count for expire3 starts its N*lc_interval
deadline only after the Days=1 poll returns (~1 debug-day in). With N=5
and lc_interval == debug_day, the 5*debug_day terms cancel and the slack
past the Days=5 due time is only ~1 debug-day (~9s) -- which a single slow
scanner cycle (observed ~13s spacing under CI load) can exceed, leaving the
count stalled at 4. Bumping the two expire3 windows to 8*lc_interval raises
the slack to ~39s, comfortably above the observed cycle jitter.

Test-only, lane-scoped: does not touch RUSTFS_ILM_DEBUG_DAY_SECS or the
4*lc_interval < 5*debug_day plateau invariant. The expire3 target count (2)
is terminal (nothing expires after it), so a wider window can never
over-expire. Also documents the #4772 RUSTFS_DATA_USAGE_UPDATE_DIR_CYCLES=1
knob in lifecycle_behavior_tests.txt.

2026-07-12 14:15:05 +00:00

..

0001-rustfs-key-limit-timeout-and-utcnow.patch

fix: stabilize s3-tests delete key-limit coverage (#4283)

2026-07-05 20:35:32 +08:00

0002-lifecycle-behavior-polling.patch

fix(ci): widen Days=5 expiration poll window to 8*lc_interval (#4779)

2026-07-12 14:15:05 +00:00