## What changed
Fixed `addFieldTerm` in `SearchBar.vue` so that include/exclude search
terms are inserted at the correct position in SQL aggregation queries.
Previously the code checked for `ORDER BY` before `GROUP BY`, causing
the injected `WHERE` clause to land after `GROUP BY` (invalid SQL). The
fix scans all terminating clauses (`GROUP BY`, `HAVING`, `ORDER BY`,
`LIMIT`) and inserts `WHERE` before whichever appears earliest. The
remaining diff is Prettier-driven reformatting with no logic changes.
## Why
The old sequential `if/else if` checked `ORDER BY` first. On a query
containing both `GROUP BY` and `ORDER BY`, it would split at `ORDER BY`
and produce `… WHERE <filter> ORDER BY … GROUP BY …` — structurally
invalid SQL. The fix enforces correct SQL clause ordering (`FROM → WHERE
→ GROUP BY → HAVING → ORDER BY → LIMIT`).
## Approach
The new algorithm iterates over all four terminating clauses, records
the index of each that is present, picks the one with the smallest index
(`firstClause`), then uses the existing `queryIndexSplit` utility to
splice the `WHERE <filter>` token in before it. If no terminating clause
exists the filter is appended. The spec file was extended with 14 new
unit tests covering the core bug scenario (GROUP BY + ORDER BY
together), each individual clause in isolation, all-clauses-present,
AND-append paths, and edge cases (case-insensitive matching, column
names containing clause keywords, special characters in filter values).
## Risk
The logic change is isolated to the `else` branch of `addFieldTerm` that
handles queries with no existing `WHERE` clause. Queries that already
have a `WHERE` clause follow a separate code path and are unaffected.
Reviewers should confirm the `queryIndexSplit` utility is
case-insensitive-safe (the fix lowercases only for the index scan, then
splits the original string) and verify the preserved trailing
`afterClause` string includes the space/newline that was previously part
of the `" order by"` / `" group by"` literals.
## What changed
Replaced `VueJsonPretty` (`vue-json-pretty`) with `CodeQueryEditor.vue`
(Monaco-based) for JSON rendering in `LLMContentRenderer.vue`. Inlined
the `MessageItem` sub-component directly into the template with
`CodeQueryEditor` for JSON message content. Added `showLineNumbers` and
`stickyScroll` props to `CodeQueryEditor`. Removed the unused
`vue-json-pretty` dependency from `package.json`. Passed unique editor
IDs from `TraceDetailsSidebar` via a new `instanceId` prop to prevent
Monaco editor ID collisions.
## Why
`vue-json-pretty` formats the entire JSON tree on initial render,
causing lag on long JSON payloads. Monaco (via `CodeQueryEditor`)
renders only visible viewport lines, making performance O(visible)
instead of O(total).
## Approach
- Replaced all 7 `VueJsonPretty` instances in `LLMContentRenderer.vue`
with `<CodeQueryEditor>` in read-only mode (`:read-only="true"`,
`:show-line-numbers="false"`, `:sticky-scroll="false"`)
- Inlined the `MessageItem` sub-component as a `v-for` block with
`CodeQueryEditor` for JSON message content and the existing `v-html`
markdown renderer for non-JSON content
- Converted the component to `<script setup lang="ts">` with
`defineAsyncComponent` for `CodeQueryEditor`
- Added `showLineNumbers` and `stickyScroll` props (both default `true`)
to `CodeQueryEditor.vue` to support the JSON viewer use case
- Added a `watch` on `showLineNumbers` to dynamically toggle line
numbers in Monaco
- Passed `instanceId` from `TraceDetailsSidebar` down to
`LLMContentRenderer` to generate unique editor IDs like
`trace-id-msg-json-editor-0`
## Considered & rejected
- **Render function approach with synchronous import of
CodeQueryEditor** — rejected because it forced manual editor height
computation and module-level counters for editor IDs. Inlining
`MessageItem` as a template component was cleaner and consistent with
the other 5 template `CodeQueryEditor` locations.
- **Retaining `MessageItem` as a separate component with render
function** — rejected because the render function approach was
over-engineering for what is now a simple `v-for` with conditional
`CodeQueryEditor` / markdown branching.
## Risk
Medium. Monaco editor initialization has non-trivial overhead; rendering
multiple editors on one page (e.g., many messages in a conversation)
could impact initial render time. Reviewers should check that the
`instanceId` prop is correctly wired from `TraceDetailsSidebar` to avoid
duplicate Monaco editor IDs, and that the `tw:h-full` class application
on content-wrapper divs doesn't break non-JSON (plain text / markdown)
layouts.
## What changed
Removed the `label` property from important field entries pushed into
`selectedStreamFields` in the traces `extractFields()` function.
## Why
The `label` field was redundant — it duplicated the `name` property —
and caused display issues in the traces fields sidebar where both `name`
and `label` were shown. The data model already uses `name` as the
display key.
## Approach
Stripped the `label: rowName` assignment from the important fields
branch in `extractFields()`.
## Risk
The field removal changes the object shape pushed to
`selectedStreamFields` for important fields. Verify that no downstream
code (field grouping, semantic matching, search building) depends on
`field.label` being present.
**Problem:**
Backend sent cumulative `took` per partition (monotonically increasing:
69, 130, 192...ms). Frontend summed all values → O(n²) inflation (e.g.
23s displayed vs 1.4s actual).
**Fix:**
- Backend: timer now created independently per partition → each
partition reports only its own processing time
**Result:** `took = search + histogram` sums correctly. Verified against
SSE data for both no-cache and cache flows
This pr fixes the issue #11450
We observed that during auto UDF execution, the _timestamp field was
being included both in the schema and the user-defined schema. The UI
was not designed to handle this duplication. This issue does not occur
when users manually add fields through the Stream page, as _timestamp is
not added to the user-defined schema in that flow. We have now handled
this scenario.
---------
Co-authored-by: Bhargav <BJP232004@GMAIL.COM>
#11446
Traces in the Logs correlation panel were showing wrong durations
because they were read from /latest (cached summaries). Using
/latest_stream delivers the actual trace records with correct duration
data.
#11463
Updated FlameGraphView.vue so that spans with a computed width below
0.1% of the total trace duration are rendered with a minimum 0.1% width
instead of being dropped — ensuring all spans remain visible regardless
of how short they are.
## Summary
- Render `summary.return_code`, `stdout_lines`, `stderr_lines`, and
`truncated` in the chat tool-call details panel so CLI tool results show
parsed info like MCP tools do.
- Whitelist `command` in `getToolCallDisplayData` and add a "Command"
row with a copy button so the actual CLI command the agent ran is
visible.
## Context
The o2-ai server already emits a uniform `tool_result` shape for CLI
tools (see openobserve/o2-ai#96 — wait for that to merge):
```json
{
"type": "tool_result",
"tool": "cli_kubectl",
"success": true,
"message": "Exited 0 (12 lines stdout)",
"summary": { "return_code": 0, "stdout_lines": 12, "stderr_lines": 0 },
"call_args": { "command": "get pods -n default" },
"call_id": "call-uuid-v7"
}
```
`ContentBlock.summary` was already being captured from the event — the
template just had no conditionals for the CLI fields. This PR adds them.
## What this does NOT do
- Does not show raw `stdout`/`stderr` text (server currently only sends
line counts). If we want inline output, that's a separate backend
change.
- Does not add a custom header format for CLI — the default
`block.message` ("Exited 0 (12 lines stdout)") renders fine as plain
text.
## Test plan
- [x] `npm run type-check` — clean
- [ ] Manually verify in dev chat that a CLI tool call (`kubectl get
pods`) shows the Exit code / Stdout / Stderr rows and the Command row
with copy button
- [ ] MCP tools (SearchSQL, StreamList) still render the existing
Results / Duration rows unchanged
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bhargav
Sai Nikhilandgithub-actions[bot]
Omkar Kesarkhane
Abhay Padamani
Ashish Kolhe
Loakesh Indiran
ktx-kirtan
