fix: clear loop detection after compression and detect text-only loops - #2058
Open
xielixing wants to merge 1 commit into
Open
fix: clear loop detection after compression and detect text-only loops#2058xielixing wants to merge 1 commit into
xielixing wants to merge 1 commit into
Conversation
After context compression succeeds, recent_tool_signatures and recent_failed_tool_signatures were not cleared. The compressed context is effectively a fresh start, so stale pre-compression tool signatures must not bias post-compression loop detection. Additionally, when the model produces text-only responses (no tool calls), recent_tool_signatures.clear() reset all loop detection, allowing the model to loop indefinitely producing identical text. This is the exact symptom described in issue GCWing#1179: after compression, the response content keeps looping. Two fixes: 1. Clear loop detection state (recent_tool_signatures, recent_failed_tool_signatures, failed_tool_recovery_attempts) at both compression success sites (primary path and overflow recovery). 2. Add text-only loop detection via recent_text_fingerprints: a normalized fingerprint of assistant text content is tracked for text-only rounds. When max_consec consecutive identical fingerprints are detected, the turn is finalized with reason "repeated_text_responses". Closes GCWing#1179
xielixing
force-pushed
the
fix/issue-1179-compression-loop-detection
branch
from
August 5, 2026 06:24
8246dc8 to
e9c88e3
Compare
xielixing
pushed a commit
to xielixing/BitFun
that referenced
this pull request
Aug 5, 2026
Three afternoon PRs ballooned to ~8.8k added lines because the agent branched its fix worktrees from the host checkout's HEAD, which sat on the in-flight feature branch; the whole feature diff rode along into each PR. The preamble now requires basing every fix branch on origin/<default> after a fetch, never on the host checkout's current branch. The three contaminated branches were rebased onto origin/main and force-pushed (PRs GCWing#2058/GCWing#2059/GCWing#2060 now carry only their own fix). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Fix: Clear loop detection after compression and detect text-only loops (#1179)
Problem
After context compression succeeds, the response content keeps looping indefinitely (issue #1179).
Root Cause
Two bugs in
execution_engine.rs:Stale loop-detection state after compression: When context compression succeeds,
recent_tool_signaturesandrecent_failed_tool_signatureswere NOT cleared. The compressed context is effectively a fresh start, but stale pre-compression tool signatures remained, biasing post-compression loop detection.No text-only loop detection: When the model produces text-only responses (no tool calls),
recent_tool_signatures.clear()was called, resetting ALL loop detection. This allowed the model to loop indefinitely producing identical text responses — exactly the symptom in [Bug]: 压缩之后回答的内容一直循环，怀疑压缩有问题 #1179.Fix
1. Clear loop detection state after compression — At both compression success sites (primary path at line ~3567 and overflow recovery at line ~3801), clear
recent_tool_signatures,recent_failed_tool_signatures,failed_tool_recovery_attempts, andrecent_text_fingerprints.2. Add text-only loop detection — New
recent_text_fingerprints: Vec<String>tracks normalized fingerprints of text-only responses (whitespace-stripped, lowercased, truncated to 500 chars). Whenmax_consecconsecutive identical fingerprints are detected, the turn is finalized with reason"repeated_text_responses".Validation
cargo check -p bitfun-corepasses (exit code 0, only pre-existing dead_code warning)Closes #1179