Frun1na opened a new issue, #6081: URL: https://github.com/apache/rocketmq-dashboard/issues/6081
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `5e4c39b0` deployed as: reproduced by a unit test against that commit (the affected code is the web client) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the web client browser: not applicable — reproduced in a jsdom unit test (vitest + Testing Library) ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed `GET /api/llm/config` in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug The home page stores a failed assistant-configuration request as "no configuration", which is a state the composer cannot explain. `web/src/pages/home/index.tsx:118` (base `5e4c39b0`): ```ts const config = await getLlmConfig().catch(() => null); if (cancelled) return; setLlmConfig(config); ``` `llmConfig` therefore stays `null` on a failure, exactly as it is before the first response arrives. The composer that the home page renders (`web/src/pages/ai/components/Composer.tsx:312` and `:425`) only renders its "provider not ready" banner and its provider status tag behind `llmConfig && ...`, and sending requires `llmReady` (`index.tsx:100-101`). So when `GET /api/llm/config` fails the page shows: - an input box whose send action never runs, - no explanation of why (the composer's not-ready banner needs a config to render), - no retry, and no way to tell the state apart from "still loading". The AI page does report this failure (`web/src/pages/settings/AiAssistantTab.tsx` toasts `llm.loadFailed` when the same request fails), so the home page is the one place where the failure is invisible. ### Steps to Reproduce Reproduced by a unit test rather than against a cluster; the request stub is the only setup needed: 1. Render `HomePage` with `getLlmConfig` rejecting (equivalently: open the console while `GET /api/llm/config` fails). 2. Type a prompt into the box and press Enter. 3. Nothing happens, and the page never says that the configuration could not be loaded. ### What Did You Expect to See? The page should report that the assistant configuration could not be loaded and offer a retry, the way the AI settings tab already does. ### What Did You See Instead? A silently disabled input box with no message and no retry. ### Additional Context - A fix with a regression test follows in a pull request. - The failure is pinned by a unit test that fails on `5e4c39b0` and passes with the fix, including the retry: after the configuration loads, the composer reports its provider status and a prompt is handed to the AI page again. ### 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]
