mirror of
https://github.com/alibaba/open-code-review.git
synced 2026-08-30 04:21:48 +00:00
9ab06166d4
tokenWarningThreshold = 0.80 is defined in internal/llmloop, but it is unexported, so the four call sites outside that package could not reach it and each hardcoded '* 4 / 5' instead. The 80% policy therefore had two encodings that could silently drift apart. Add llmloop.PromptTokenLimit and route all six sites through it: internal/agent/agent.go:594, 790 internal/scan/agent.go:321, 555 internal/llmloop/compression.go:99 internal/llmloop/loop.go:440 loop.go:439's softLimit stays inline; it uses the separate 60% tokenSoftThreshold, which has a single consumer and stays unexported. Behaviour is unchanged. 0.80 in float64 is strictly above exact 4/5, so for positive x the product never rounds below the exact value and truncation lands on the same integer; verified over x in [-5_000_000, 5_000_000] with zero divergences. The float form is also the more robust of the two: x*4 overflows int64 above MaxInt64/4, where the old expression silently returned 0 (i.e. no limit). The <= 0 guards stay at the call sites. filterLargeDiffs/filterLargeScans treat a non-positive limit as keep-everything, while the pre-flight gates treat it as a ceiling that rejects every prompt, so the helper does not special-case it. Tests: TestPromptTokenLimit pins the arithmetic with hand-computed expectations, and new boundary tests pin the threshold itself - with MaxTokens=100 an exactly-80-token input is kept and an 81-token one dropped. The pre-existing filter tests survive mutating the constant to both 0.75 and 0.85; the new ones fail on both. Closes #417 |
||
|---|---|---|
| .. | ||
| agent.go | ||
| agent_test.go | ||
| batch.go | ||
| batch_test.go | ||
| budget_test.go | ||
| coverage_test.go | ||
| dedup_test.go | ||
| estimate.go | ||
| estimate_test.go | ||
| init_test.go | ||
| preview.go | ||
| provider.go | ||
| provider_test.go | ||