fix(telegram): keep group history always on#99143
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 2, 2026, 12:20 PM ET / 16:20 UTC. Summary PR surface: Source +84, Tests +360, Docs -5, Generated 0, Other 0. Total +439 across 24 files. Reproducibility: yes. at source level: current main defaults Telegram group history to Review metrics: 1 noteworthy metric.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Land a coordinated Telegram ambient-history fix only after explicit Do we have a high-confidence way to reproduce the issue? Yes, at source level: current main defaults Telegram group history to Is this the best way to solve the issue? No, not as currently written. The Telegram-local rolling window is the right layer, but the migration is not the safest fix until explicit Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 0c82908f78e9. Label changesLabel justifications:
Evidence reviewedPR surface: Source +84, Tests +360, Docs -5, Generated 0, Other 0. Total +439 across 24 files. View PR surface stats
Security concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
c70ffdf to
506af8f
Compare
506af8f to
05a8b31
Compare
Closes #99142
What Problem This Solves
Ambient group mode (
unmentionedInbound: "room_event") runs blind: 74% of room-event turns in a production deployment carried zero conversation context, so the model judged isolated fragments and over-replied. Two mechanisms cause this inextensions/telegram: PR #89547'sincludeGroupHistoryContextdefault (mention-only) gates the pending group-history window off for exactly the unmentioned traffic ambient mode exists to observe, and the window lifecycle destructively wipes on every non-room-event turn and on room-event delivery — unrecoverable, since room events are deliberately not session-persisted. The window also never containeduser_requestmessages or the bot's own sends, so even populated windows omitted the conversation happening with the bot.Why This Change Was Made
Maintainer decision (discussed among maintainers): remove what #89547 added rather than re-default it. The option shipped 2.5 weeks ago (v2026.6.10), conflates prompt-context filtering with ambient-mode viability, and its default silently blinded ambient rooms;
historyLimit(including0to disable) remains the single knob. The window becomes a rolling window: all group inbound (both event kinds) is recorded at one site, the bot's own outbound sends are recorded self-labeled via an account-scoped recorder registered by the monitor, and the legacy "messages since your last reply" semantics for addressed turns are preserved non-destructively by selecting entries after the last self-entry instead of clearing. Room-event turns receive the full rolling window including the bot's own posts so the model can self-regulate reply frequency. Per the retired-key policy,openclaw doctor --fixstripsincludeGroupHistoryContextfrom existing configs —"none"maps tohistoryLimit: 0to preserve the privacy intent, and an account-level"recent"under a root"none"pins the account's pre-migration effective limit. The ambient invariants are pinned inextensions/telegram/AGENTS.mdso history-gating regressions of this class get caught in review.User Impact
Ambient-mode agents see recent room activity again and stop treating lone fragments as direct requests — the dominant cause of "the bot chimes in constantly" reports.
requireMentiondeployments keep their existing prompt-history behavior (bounded byhistoryLimit, watermarked at the bot's last reply). Configs still carryingincludeGroupHistoryContextget a doctor warning and a clean--fixmigration; no startup break.Evidence
mention-onlydefault."none"→historyLimit: 0mapping; config carrying the retired key does not brick startup.pnpm tsgo:extensions;node scripts/run-vitest.mjsover the 8 touched Telegram test files (502 tests); oxlint clean;pnpm config:channels:check; repo autoreview (branch mode) clean; combined-tree validation with the two sibling PRs: both tsgo lanes + 16 test files + Linux Testbox prompt-snapshot and changed-lanes gates.