fix: short-circuit identical compress failures (#156) - #182
Open
ranxianglei wants to merge 1 commit into
Open
Conversation
A small model (2B) retried the same failed compress range with the same validation error for all 10 loop rounds — each retry a real upstream call (issue #156 field logs). runCompressLoop now fingerprints failed compress calls per round (requested refs + failure text with volatile numbers collapsed) and completes gracefully after two consecutive identical failures instead of re-requesting a third time. Distinct failures still keep the loop alive. Also makes the 0-ranges compression failure message actionable: each range needs string startId/endId refs plus a summary; acp_status lists currently valid refs.
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.
Problem (#156)
Field logs from a 2B model (Codex + Responses, v0.1.27): the model retried the same failed compress range with the same validation error (
Summary too short (28 chars…)×6) for all 10 loop rounds. Every retry was a real upstream call — up to 10 wasted requests + tokens per session, with zero chance of the model self-correcting since it re-sent byte-identical arguments.Fix
1. Identical-failure short-circuit (
src/loop/core.ts)compressFailureSignature()fingerprints each round's failed compress calls: requested refs (startRef..endRef, fromparseCompressInput) + the failure text with volatile digits collapsed (so28 charsand31 charscount as the same failure class). After two consecutive rounds with an identical signature,runCompressLoopcompletes gracefully (finishReason: "length", same as the round-limit path) instead of re-requesting a third time.[acp-loop] compress loop short-circuited (identical failure twice): …for observability.2. Actionable 0-ranges failure text (
src/stream.ts)no valid ranges parsednow tells the model how to recover: each range needs stringstartId/endIdrefs plus a summary, andacp_statuslists currently valid refs.Test adaptation
tests/fix-stream.test.tsclient-abort control arm replayed a byte-identical failing round, which the new short-circuit now (correctly) stops after 2 rounds. The fetch mock now varies the failing range per round so the control still measures what it was built to measure: without an abort signal, the loop runs to the round limit.Tests
tests/compress-shortcircuit.test.ts(3): identical failure twice → exactly one re-request; distinct failures → loop continues; 0-ranges failure carriesacp_statusguidance.tsc --noEmitclean.Fixes #156 (items ① and ②; ③ shipped in v0.1.44 via compress.prompts; ④ tag-echo stripping tracked separately).