-
released this
2026-08-10 21:02:59 -05:00 | 33 commits to main since this releaseAdded
-
RETAIN_PREVIOUS_PATCH=falsenarrows retention to the current patch.The default is unchanged (
true, the two-patch window README describes), so
nothing moves for a deployment that does not set it.It is one flag with two effects, and they cannot be separated: it sets the
windowpruneToPatchesenforces AND whetherpreviousPatchreaches the
damage and benchmarks builders as their thin-sample fallback. Pruning the rows
while still naming the predecessor would publish
generatedFrom.previousPatch: "16.14"over four queries that return nothing —
provenance for a fallback that cannot fire.runRiotWindowbinds it once, as
retained, and everything downstream reads that rather than the parameter.What switching it off costs is one morning per patch: on rollover, a champion
or role with no rows yet on the new patch is omitted from damage and
benchmarks instead of being served from the previous patch flaggedstale.
Only those two artifacts have a fallback to lose — counters, runes, synergies
and builds are current-patch-only either way — and neitherdata/archivenor
the brotli'd published payloads are pruned under either setting.It also forgets the previous patch's
seen_matchids, so rollover morning
re-fetches some matches it already knows are off-patch and discards them
again. Bounded, and once per patch.The deployed stack sets it, alongside a crawl window widened from three hours
to six: 6-hour nights collect roughly twice the rows, and holding two patches
of that on the shared Postgres is ~1Mparticipant_statrows. The wider
window is also what makes the trade cheap — most champion-roles now have rows
by the first morning, so the fallback rarely fires at all.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-