fix(plugins): stop duplicate_spam from starving bio_bait_spam at group=4#21
Merged
Conversation
duplicate_spam and bio_bait_spam register at the same PTB group (4) with the identical filter shape (GROUPS & ~COMMAND). PTB checks handlers in registration order within a group and stops at the first match by default (block=True), and duplicate_spam registers first per MANIFEST_ORDER — so bio_bait_spam's callback has never actually run for a real update. Set block=False on both registrations so PTB keeps checking the next handler in group=4 after the first one runs. ApplicationHandlerStop (raised on an actual detection in either handler) still short-circuits the rest of the pipeline as before, so this only affects the common case where neither handler finds anything to act on.
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
1 participant
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
duplicate_spamandbio_bait_spamboth register at PTBgroup=4with the identical filter (GROUPS & ~COMMAND)block=True);duplicate_spamregisters first perMANIFEST_ORDER, sobio_bait_spam's callback has never actually fired on a real updateblock=Falseon both registrations so PTB keeps checking the next handler in the group instead of stopping after the first matchApplicationHandlerStop(raised when either handler actually detects spam) still short-circuits downstream processing as before — this only changes the common case where neither handler finds anything to act onTest plan
uv run pytest- 988 passeduv run ruff check .- cleanuv run mypy src/bot/ tests/- cleanblock is Falseon both handlers, named after the collision so future refactors can't silently reintroduce it