tju-yxq opened a new issue, #6154: URL: https://github.com/apache/rocketmq-dashboard/issues/6154
> Resubmission of #5401 — the original report was closed by the repo's 7-day stale bot for inactivity, not because it was fixed or rejected; the problem is still reproducible on the current `rocketmq-studio` head. An updated PR carrying the fix is being filed against this report. ## Problem The manual trace query is the one path for the custom trace topic that does not trim its input. Typing or pasting a whitespace-padded topic — ` RMQ_SYS_TRACE_TOPIC ` — into the trace tab and clicking 查询轨迹 sends the **padded** string to the trace API, which looks up a topic that does not exist and returns nothing, while the identical input works everywhere else: opening the trace through a row's 轨迹 button trims the field before both the request cache key and the request itself, the persistence layer stores the trimmed value, and query-history replay restores it trimmed. The same dialog, same field, two behaviors depending on which button started the query. ## What did you do (steps to reproduce)? 1. Open a message query, run it, and open a row's 轨迹 tab (or switch the trace panel to 按 Message Key). 2. Type a padded custom trace topic, e.g. ` CUSTOM_TRACE ` (padding commonly comes from pasting out of a ticket or chat). 3. Enter a valid key and click 查询轨迹. 4. The query returns nothing (or an error) — the API was called with the padded topic. 5. Clear the field, type the same topic without padding: the query works. ## What did you expect to see? The manual query normalizes the topic like every other path for the same field. ## What did you see instead? The raw padded string is sent, and the trace lookup fails for input that differs from the working value only by whitespace. ## Root cause `web/src/pages/instance/message.tsx`, `runTraceQuery` (around lines 690-698): ```tsx ? await getMessageTraceByKey(value, selectedInstanceId, selectedMsg?.topic, customTraceTopic) : await getMessageTrace(value, selectedInstanceId, selectedMsg?.topic, customTraceTopic); ``` The sibling path in the same feature, `loadMessageTrace` (line 614), normalizes first — `const normalizedTraceTopic = customTraceTopic.trim();` — and uses it for both the cache key and the request. The manual path trims the query value itself (line 673, `const value = traceQueryValue.trim();`) but the topic argument was left raw. The storage layer also trims: `MessagePageAsyncState.test.tsx` proves typing ` CUSTOM_TRACE ` persists `CUSTOM_TRACE` — so the manual query is the sole untrimmed path. ## Expected behavior - The manual trace query (both key and message-id modes) sends the trimmed custom trace topic. - The row-opened path, persistence, history replay and all other behavior are unchanged. ## Acceptance criteria - [ ] Regression proof: on the current code, a padded topic is passed raw to `getMessageTraceByKey`; with the fix, the trimmed value is passed. - [ ] The message-id mode also receives the trimmed topic. - [ ] The row-opened trace path is unchanged. - [ ] Existing trace tests stay green. ## Environment Branch `rocketmq-studio` at `6a68042f`; file: `web/src/pages/instance/message.tsx`. ## Duplicate check Searched open and closed issues for `trace topic` and `whitespace trim`: #2643 (closed — history losing the custom topic selection) and #4143 (closed — AI tool custom trace topic) are adjacent features; neither covers the manual query's untrimmed argument. The open #5358/#5200 are unrelated (preference leakage, exportability). -- 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]
