zmuxuny opened a new issue, #6029: URL: https://github.com/apache/rocketmq-dashboard/issues/6029
### 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 commit: 4ee173ad71ae777f01111394a88358958b9abad6 Reproduced in repository tests; production implementation unchanged. ### Runtime Environment Debian 13 Linux, Node.js 24.19.0, Vitest 4.1.10 with native ReadableStream/Response fixtures. No deployed browser or MySQL instance was used. ### Connected RocketMQ Cluster None. The defect is in the browser AI run-stream transport; a synthetic SSE response is sufficient. ### Build Toolchain Node.js 24.19.0; dependencies from the committed package-lock.json. ### Describe the Bug ## Tracking continuation (2026-10-10) This replaces #5186, which was automatically closed by github-actions[bot] for inactivity on 2026-10-09. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. Existing fix PR #5187 remains open and ready for review. This replacement restores issue tracking for that PR without creating another implementation. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5186. The browser reader resolves successfully when the HTTP body closes before event: done, for both openRunStream and attachRunStream. A complete text_delta frame followed by EOF is accepted as normal termination. The idle watchdog cannot detect this because reader.read() immediately returns done: true. AgentStreamSession.complete() sends the done control frame before closing a normal stream. An observer can instead disconnect while the server-side run continues. useAgentRun surfaces transport failures through its error path, but premature EOF never enters that path. An attached run can therefore stop receiving updates without an explanation; useActiveRunAttach intentionally attempts each run only once per visit. This does not mean the backend marks the run COMPLETED. ### Steps to Reproduce 1. In web/src/api/ai.test.ts, return a 200 text/event-stream Response containing the complete frame: event: agent\ndata: {"type":"text_delta","content":"partial"}\n\n 2. Close the response body without an event: done frame. 3. Call openRunStream; repeat with attachRunStream. 4. Assert rejection with an AiStreamError identifying premature EOF. Ran cd web && npm test -- src/api/ai.test.ts with two added regression cases: 2 failed, 27 passed. Both failures: promise resolved "undefined" instead of rejecting. The text delta was delivered. ### What Did You Expect to See? A structured AiStreamError for EOF before normal transport termination. Preserve already-delivered frames and existing timeline recovery; do not automatically resend a message or stop the server-side run. Normal done frames, error frames, explicit aborts, idle timeouts, and reader cleanup should retain their behavior. ### What Did You See Instead? Both stream promises resolve successfully with undefined after a partial response. No transport error is surfaced for the missing terminal control frame. ### Additional Context Searched issues and PRs for stream EOF, premature termination, truncated streams, terminal frames, and disconnects. #437 covers the old parser fragmentation path; #1564 and #2208 concern server/provider timeout and cancellation. #5184 concerns mixed line endings, not premature closure. This report was prepared with AI assistance and the regression was run against the exact revision above. No live model, broker, database, or browser end-to-end validation is claimed. A focused fix with regression coverage will follow. ### 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]
