Frun1na opened a new issue, #4694: URL: https://github.com/apache/rocketmq-dashboard/issues/4694
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: rocketmq-studio git commit id: 7ce9a68215c4cd1c7025013d02135b43b6aa6ba1 deployed as: built from source (`cd server && mvn -B -ntp package -DskipTests`) ### Runtime Environment OS: Windows 11 with WSL2 (Ubuntu 24.04.3 LTS) MySQL: 8.0.36, container from `deploy/docker-compose.yml` browser: not involved (server-side defect) ### Connected RocketMQ Cluster Not involved: the defect is in the hosted AI conversation platform's run lifecycle, verified by code inspection and unit tests with a stubbed provider. ### Build Toolchain JDK 21, Maven 3.9.9 ### Describe the Bug A hosted AI conversation remembers the runtime session id of its last run in `rmq_ai_conversation.runtime_session_id` so that the next turn can `--resume` it. The id is durable; the CLI workspace that holds the session (`RmqctlWorkspace`, under `/tmp`) is not. After the server container restarts, the workspace is gone while the id is not. The CLI then fails every subsequent turn the same way: exit code 1, `No conversation found with session ID: <id>` on stderr, and one `result` frame with `subtype: error_during_execution`. That frame echoes the *requested* session id back — `ClaudeCodeStreamParser` documents exactly this, and states that a caller must not persist the session id of a run that did not succeed. `AiRunExecutor.record` persisted it anyway, in two places: `rmq_ai_run.runtime_session_id` and, through `rememberRuntimeSession`, `rmq_ai_conversation.runtime_session_id`. So the dead id is written back over itself, and every later turn resumes the same missing session. The conversation never recovers, and nothing in the UI says why. `ResumeRecovery` in `ops/ai/conversation/agent/` already specifies the repair — on the lost-resume signal, retry the turn once without `--resume` and clear the remembered id — and `docs/ai-agent-architecture.md` states the same requirement. Neither is reached: `grep -rn ResumeRecovery server/src` finds the class and one test that calls its static predicates, and no production caller. The recovery is dead code. ### Steps to Reproduce 1. Configure an instance with the `claude-code` engine and send a message so that a run completes and the conversation stores its runtime session id. 2. Restart the server container, which wipes the `/tmp` workspace the CLI session lived in. 3. Send another message in the same conversation. ### What Did You Expect to See? The turn is retried once without `--resume`, and the conversation continues with a fresh session. Earlier turns' context is lost, which `ResumeRecovery` documents as the accepted price; the conversation keeps working, and afterwards `runtime_session_id` holds the new session rather than the dead one. ### What Did You See Instead? Every turn fails with `error_during_execution`, and the failure writes the unusable session id back, so the next turn repeats it. The conversation is permanently broken and has no recovery path from the UI. ### Additional Context `ClaudeCodeStreamParser`'s javadoc already warns about the echoed id ("a caller must not persist the session id of a run that did not succeed"), and `AgentRunHandle` already anticipates a second spawn for a resume-recovery retry ("An AtomicReference rather than a plain field because a resume-recovery retry legitimately spawns a second process for the same run"), so the intended design is in the code; only the wiring is missing. I have a fix ready: PR #4693. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
