fix(agentchat): MessageFilterAgent count=0 returns no messages instead of all#7915
Open
nolanchic wants to merge 2 commits into
Open
fix(agentchat): MessageFilterAgent count=0 returns no messages instead of all#7915nolanchic wants to merge 2 commits into
nolanchic wants to merge 2 commits into
Conversation
…d of all
In MessageFilterAgent._apply_filter, the per-source slice guards used a
truthiness check on count ('and source_filter.count'). Since 0 is falsy,
count=0 skipped slicing entirely and returned ALL messages from that
source — the opposite of the intended behavior. The class docstring
states that 'If position is None, all messages from that source are
included', so count=0 (with position set) should mean zero messages.
Additionally, even after switching to 'is not None', the 'last' branch
would still return all messages for count=0 because msgs[-0:] is
equivalent to msgs[0:] (the whole list). Handle count <= 0 explicitly by
returning an empty list.
Add a focused test module covering count=0 (first/last), count=None
(all messages preserved), and positive counts.
Following review feedback, constrain PerSourceFilter.count with Field(default=None, ge=0) so negative values are rejected at the model boundary (fail-fast) rather than silently coerced inside _apply_filter. Since negative values can no longer reach _apply_filter, the defensive 'count <= 0' branch is tightened to 'count == 0' (which still needs explicit handling because msgs[-0:] returns the whole list). Also add a docstring to PerSourceFilter clarifying the count semantics: 0 means 'no messages', None means 'do not slice'. Add a test asserting negative count raises ValidationError at construction.
Author
|
Added a follow-up commit to harden the boundary validation:
All checks still green: 81 passed (5 message-filter + 76 graph), ruff/pyright/mypy clean. |
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.
Why are these changes needed?
In
MessageFilterAgent._apply_filter, the per-source slice guards used a truthiness check oncount:Since
0is falsy,count=0skipped slicing entirely and returned all messages from that source — the opposite of the intended behavior.The class docstring states:
So the intended way to keep all messages is
position=None; acount=0withposition="first"/"last"should mean zero messages. (PerSourceFilter.countisOptional[int], so0is a valid, explicit user input.)There is a second, subtler issue: even after switching to
is not None, thelastbranch would still return all messages forcount=0, becausemsgs[-0:]is equivalent tomsgs[0:](the whole list) in Python.Fix
Handle
count <= 0explicitly by returning an empty list, and switch the remaining guards from truthiness tois not None:Behavior summary:
countposition0first/lastNone>0first/lastRelated issue number
N/A — no existing issue. Edge-case correctness fix; happy to open a tracking issue if maintainers prefer.
Checks
tests/test_message_filter_agent.pycoveringcount=0for bothfirst/last,count=Nonepreserving all messages, and positive-count sanity. Thecount=0last-position case fails onmainand passes with the fix.)Local verification