Loading
Upgrade gitlab-labkit to 4.6.0
What does this MR do and why?
Upgrades gitlab-labkit from 4.5.0 to 4.6.0 and synchronizes Gemfile.lock and Gemfile.next.lock.
4.6.0 adds ban_for on a counting rate limit rule and Limiter#clear (labkit-ruby!346). Nothing in gitlab-rails uses either yet; this is the release that lets the git basic auth ban migration proceed.
cells-mailroom/Gemfile pins gitlab-labkit "~> 2.6" on its own and is deliberately out of scope here.
This is not just a version bump, please read the second commit
4.6.0 also changes the shape of every labkit rate limit Redis key, not only ban keys. The limiter, rule and characteristics now sit inside a Redis Cluster hash tag:
before labkit:rl:applimiter_test_action:limit_test_action:user:1:project:2
after labkit:rl:{applimiter_test_action:limit_test_action:user:1:project:2}The tag exists because the ban script reads a counter and writes its ban in one call, and Redis Cluster rejects a script whose keys span slots.
Two consequences
In-flight counters are abandoned on deploy. Every existing counter key is orphaned, so a caller mid-window gets a fresh allowance once. Most windows are short, 88 of the applimiter rules use 1.minute, but 9 run for 8.hours or 1.day. Those include anti-abuse counters: limit_phone_verification_sends_by_user, limit_phone_verification_verifies_by_user, limit_projects_created_by_user, limit_groups_created_by_user and the email failure limits. So the reset hands out a fresh daily allowance on those. One-off, but worth a deliberate decision rather than a side effect, which is why I have asked @reprazent whether to make the tag conditional before this merges.
37 specs asserted on literal key strings and had to follow. That is the second commit, across 7 files. The one prefix glob keeps its opening brace and no closing one, since the wildcard covers the rest of the tag.
Specs only. No production code builds or matches these keys; I grepped lib, ee/lib, app and ee/app, and the only hit is a comment.
References
Edited by Nidhey Indurkar