test(user): look up bans by user_id filter to avoid pagination flake#259
Open
nijeesh-stream wants to merge 1 commit into
Open
test(user): look up bans by user_id filter to avoid pagination flake#259nijeesh-stream wants to merge 1 commit into
nijeesh-stream wants to merge 1 commit into
Conversation
UserTest's ban / shadow-ban / unban tests query the global ban list with
no filter and assert the just-banned user appears in the response. The
shared CI app accumulates zombie bans whenever a prior job dies before
its inline teardown fires, so the just-created ban routinely ends up
past the first page of query_banned_users and the assertTrue(anyMatch)
checks fail (and the shadow-ban findFirst().get() throws
NoSuchElementException).
Add two test helpers:
- findBanFor(userId): runs query_banned_users with
filter_conditions={"user_id": {"$eq": userId}} so the lookup is
independent of pagination.
- bestEffortUnban(userId): clears regular + shadow bans in a finally
block so the test app stops accumulating zombies even when an
assertion fails.
Refactor the five failing UserTest methods (whenBanUser_thenIsBanned,
whenBanUserWithDeleteReactions_thenIsBanned,
whenShadowBanUser_thenIsShadowBanned,
whenListingBannedUsers_thenContainsBanned,
whenUnbanUser_thenIsNotBannedAnymore) to use the helpers and tidy up
after themselves.
Also tighten the @BeforeAll cleanupLeftoverBans sweep so it actually
drains shadow and channel-scoped bans (which the previous version
silently skipped because it always called unban() with no qualifiers
and bailed as soon as those bans were the only ones left on the first
page).
Co-authored-by: Cursor <cursoragent@cursor.com>
xicoalmeida
approved these changes
May 27, 2026
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
findBanFor(userId)test helper that callsquery_banned_userswithfilter_conditions={"user_id": {"$eq": userId}}, so the moderation tests stop depending on which slice of the global ban list happens to come back on the first page of the shared CI app.bestEffortUnban(userId)helper used fromfinallyblocks so each test cleans up after itself (regular + shadow), preventing the shared app from accumulating zombie bans.UserTestmethods that were failing on every recent CI run (including the scheduled jobs onmain, e.g. run 26395993503) to use the helpers:whenBanUser_thenIsBanned,whenBanUserWithDeleteReactions_thenIsBanned,whenShadowBanUser_thenIsShadowBanned,whenListingBannedUsers_thenContainsBanned,whenUnbanUser_thenIsNotBannedAnymore.@BeforeAll cleanupLeftoverBanssweep so it actually drains shadow and channel-scoped bans. The previous version always calledUser.unban(id).request()with no qualifiers, so any first page dominated by shadow / channel zombies caused it to bail withunbannedThisRound == 0and leave the queue stuck.Root cause
User.queryBanned().request()returns a paginated slice (limitdefaults to ~50, max 300). The shared test app accumulates zombie bans whenever a prior PR's job dies before its inline teardown fires. Once enough pile up,bans.stream().anyMatch(ban -> ban.getUser().getId().equals(userId))fails because the just-banned user is past page 1, andfindFirst().get()in the shadow-ban test throwsNoSuchElementException. Filteringquery_banned_usersbyuser_idmakes the lookup deterministic regardless of zombie count.Test plan
./gradlew compileTestJava(JDK 11 toolchain)./gradlew spotlessCheckTest & lintjob passes the five previously failingUserTestcasescleanupLeftoverBanssweep keeps draining the CI app over subsequent runs (visible in successive@BeforeAlltimings / scheduled main runs)Made with Cursor