Fix get_post_content silently dropping comment_depth#9
Open
johntrandall wants to merge 1 commit into
Open
Conversation
get_post_content accepts a comment_depth parameter, but inside the function the call to get_post_comments dropped it. get_post_comments then called _build_comment_tree(node) with no depth argument, defaulting to 3 every time — so the user-supplied comment_depth had no effect and threads silently truncated at depth 3. Symptom: callers pass comment_depth=10 expecting deep threads; tree truncates at 3 regardless. Found while sweeping a Reddit thread where the answer to a user's question lived at depth 4. Fix: thread depth through get_post_comments and into the recursion. Adds three regression tests covering the default, the propagation through get_post_comments, and the bug-site propagation through get_post_content. Claude-Session-Id: $CLAUDE_SESSION_ID Resume: claude --resume $CLAUDE_SESSION_ID
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.
What this changes
Three-line fix in
src/mcp_server_reddit/server.py: threadcomment_depthfrom
get_post_contentthroughget_post_commentsinto_build_comment_tree.def get_post_content(self, post_id, comment_limit=10, comment_depth=3): ... - comments = self.get_post_comments(post_id, comment_limit) + comments = self.get_post_comments(post_id, comment_limit, depth=comment_depth) -def get_post_comments(self, post_id, limit=10): +def get_post_comments(self, post_id, limit=10, depth=3): ... - comment_tree = self._build_comment_tree(node) + comment_tree = self._build_comment_tree(node, depth=depth)Why
get_post_contentacceptscomment_depthfrom the client andcall_toolforwards it, but the call toget_post_commentsdrops the argument, so_build_comment_treealways falls back to its defaultdepth=3. Net effect: the user-suppliedcomment_depthhas no effect — threads silently truncate at 3 levels regardless of the requested depth.Tests
tests/test_comment_depth.py— three regressions, all pass:test_get_post_comments_default_depth_is_3— default unchangedtest_get_post_comments_respects_depth_arg— depth propagates insideget_post_commentstest_get_post_content_propagates_comment_depth— bug site:get_post_contentpasses the right args downstreamVerified empirically against a Reddit thread where
comment_depth=10previously returned the same truncated tree as the default; after the fix the full chain comes back.🤖 Generated with Claude Code