3219378872 opened a new issue, #5097:
URL: https://github.com/apache/rocketmq-dashboard/issues/5097
## Problem
Starting a new AI conversation from the home page or `/ai` does not let the
operator select or see the RocketMQ instance the conversation will control.
On `rocketmq-studio` at `a562601d0971001c1cd3b888a9f2664b6ef77811`:
- `AiPage.handleSend` passes `{mode}` to `useAiSend`, without an instance.
- `HomePage.handlePromptSubmit` carries the prompt/model/engine to `/ai`,
without an instance.
- `useAiSend.withDefaultInstance` loads the instance directory and silently
picks the first entry with `adminCredentialRef`, otherwise the first entry.
- Neither composer shows the resulting binding.
With `prod` and `staging` instances, an operator starting a new conversation
cannot establish which target will be bound before submitting the prompt.
Backend binding checks keep a session on its chosen instance, but do not
establish that the initial choice matches the operator's intent.
Source:
[useAiSend.ts](https://github.com/apache/rocketmq-dashboard/blob/a562601d0971001c1cd3b888a9f2664b6ef77811/web/src/pages/ai/hooks/useAiSend.ts#L127).
## Proposed scope
Add explicit instance selection and a visible conversation target, using the
existing conversation `instanceId` contract:
1. The home-page and new-conversation composers offer an instance selector
and clearly identify its selected canonical Studio instance.
2. Creating a conversation uses that selection, including the home-to-AI
draft handoff. Do not choose a target from the instance directory's ordering or
from the presence of credentials.
3. Retain an explicit unbound/plain-chat choice if that remains a supported
product flow; it must be distinguishable from a failed directory lookup.
4. Existing conversations display their persisted bound instance and keep it
fixed. Selecting a different target starts a new conversation rather than
rebinding history.
5. Loading failures have a retry state; removed/unavailable instances do not
silently fall back to another target.
6. Keep the existing server-side target checks and tool authorization. This
change does not add cross-instance tool execution.
This addresses the visible target/context requirement in AI-01.1 without
changing the tool catalog, provider protocol or credentials model.
## Verification plan
- Regression tests with two instances in both orderings, one credentialless
instance, a failed directory lookup, and a selected instance removed before
creation.
- Test the home-page draft handoff and direct `/ai` entry.
- Load an existing conversation and verify its binding remains visible and
cannot change as directory data refreshes.
- Run frontend tests, lint and production build; inspect both languages in a
browser and capture the create-conversation request to verify the chosen target.
## Coordination
I checked the current open issues/PRs and the existing `withDefaultInstance`
implementation. The MCP instance-discovery proposal #5016/#5017 and
tool-playground fix #4957/#4958 address different entry points.
Please confirm the desired unbound/plain-chat behavior and whether this
design fits the current conversation UX before implementation. I am willing to
implement it and follow up on review. This proposal used AI-assisted source
analysis; no live production session or model call was used as evidence.
--
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]
