Summary of my work since the last summary: - I confirmed the change does not force an immediate hard reset every time. - The new behavior is: - the Anthropic malformed

tool_use

/

tool_result

error is classified into the same recovery path as context-window exceptions, -

Agent.step()

then emits a

CondensationRequest

, - and the configured condenser decides what happens next. - For

LLMSummarizingCondenser

, that means: - it is treated as a hard condensation trigger, - but a hard context reset only happens if normal condensation cannot be produced. Checklist: - [x] Answered your follow-up question directly. - [x] Clarified the exact control flow distinction between “hard trigger” and “hard reset.” - [x] No new code changes were made after that clarification. - [x] No extraneous changes were introduced in this step. So the concise answer is: yes, it kicks the error into the hard-condensation recovery pipeline, but no, it does not guarantee an immediate hard reset in every case.

Since my last summary, no additional code changes were made. Final status: - [x] The request has been fully addressed. - [x] The PR description was updated to make the behavior explicit: - these Anthropic malformed-history errors are intended to be captured and retried with condensed history - this does not mean an immediate hard reset every time - regular condensation may happen first - hard condensation/reset is only a fallback if the configured condenser needs it - [x] The branch was pushed and the PR was opened: #2613 - [x] The instructions were followed faithfully, including making the PR explanation explicit about original intent and the distinction between regular vs hard condensation. Conciseness: - [x] The changes are concise. - [x] No extraneous follow-up changes were added after that update. - [x] The work remains limited to the targeted classifier/test updates plus the clarified PR description.

Final summary: - [x] Clarified the implementation and PR text to make explicit that this change does not guarantee an immediate “hard” condensation. - [x] Updated the PR description to say the intended behavior is to capture these malformed-history errors and retry with condensed history, with regular condensation first when available and hard reset as a fallback. - [x] Posted the requested PR comment verbatim, with the intro “Hi, I'm OpenHands-GPT-5.4.” - [x] Included my thoughts on the Slack follow-up discussion exactly as requested. Conciseness: - The new work was limited to communication updates only: clarifying wording and posting the requested PR comment. - No additional code changes were introduced beyond that.

Final summary: Since the last summary, I: - posted the requested PR comment verbatim, with the exact wording you asked for and the intro “Hi, I'm OpenHands-GPT-5.4” - answered your logging/observability question based on the code paths already examined Answer to your question: - No, we do not currently have enough logging to fully address Calvin’s concern. - We have some low-level debugging support: - failed LLM calls can be captured by telemetry error logs with exception type/message/traceback and request context - But we do not have enough high-level structured observability to avoid hiding this class of bug when recovery succeeds: - the malformed-history error gets remapped into a generic

LLMContextWindowExceedError

- the agent logs a generic “context window exceeded, triggering condensation” warning - if recovery succeeds, there may be no top-level conversation error visible to users/operators - So: - manual forensic debugging may be possible sometimes - but production visibility/tracking is not sufficient - Calvin’s concern is valid: successful recovery can make a real underlying bug look like a normal condensation event Checklist: - [x] Posted the requested PR comment exactly as instructed - [x] Answered whether current logging is sufficient - [x] Focused only on new work since the last summary - [x] No extra code changes were made in this final step Conciseness: - The new work was concise: - one PR comment - one direct analysis of the current logging behavior - No extraneous repository changes were introduced in this step.