You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 465c0df
Browse filesBrowse the repository at this point in the historyBrowse files
fix(ai): preserve target evidence for plural Hub run kinds (#1748)
## What a user sees
An investigation can reach a sound conclusion and show the raw tool
calls in Activity, yet Findings shows little or no evidence for the
workload. The evidence was collected; the UI put it in the wrong bucket.
This is most visible when opening an investigation saved by Hub for a
workload such as `dev/cloud-provisioner`.
## Why this happens
Kubernetes gives the same object two names in different contexts:
| Where the name comes from | Example |
| --- | --- |
| The resource page/API URL names the *collection* | `deployments` |
| The fetched object and many tool results name its *Kind* |
`Deployment` |
The investigation stores a target—what the user asked Radar to
investigate. Findings then checks each tool result against that target
to decide whether it is evidence **about this workload** or merely
**broader context**. Some Hub runs saved the collection name
`deployments` as the target, while the evidence says `Deployment`. The
previous exact-text comparison said they were different, so relevant
events, changes, issues, and resource results could be treated as
context instead of target evidence. Reopening a saved run kept the
mismatch.
## What the fix does
1. **Starting an investigation:** when the resource page has loaded the
Kubernetes object, it sends the object's actual Kind (`Deployment`). If
it has not loaded yet, Radar uses its known Kubernetes resource
definitions or API discovery to translate `deployments` to `Deployment`.
Repeated starts take the same path.
2. **Reading an existing Hub run:** no migration or Hub API change is
needed. Findings accepts a saved target named either `Deployment` or
`deployments`.
3. **Sorting evidence:** Findings compares the *resource identity*, not
the spelling of Kind: API group, plural resource name, namespace, and
object name. Thus `apps/Deployment dev/cloud-provisioner` and
`apps/deployments dev/cloud-provisioner` match. The API group matters
because two different resources can both be named `pods`—a normal Pod
and `metrics.k8s.io` PodMetrics must not be conflated. Tool arguments
that still use plural names match by the same rule.
4. **Run state and history:** the running-investigation lookup treats
singular and plural spellings as one target, and saved-run labels show
the proper Kind when Radar knows it.
For an unfamiliar CRD before API discovery, Radar keeps its valid plural
resource name instead of inventing a singular Kind. That may leave the
label less specific briefly, but cannot send a fabricated Kind or merge
two API groups by accident. Some MCP tools, including `get_events`,
cannot specify an API group; Findings infers their intended group from
the investigation target, so a same-named resource in another group
cannot always be distinguished from the tool result alone. This PR does
not change that producer limitation.
## Verification
- Radar web: 1,153 tests passed. Shared k8s-ui: 3,680 passed, 1 existing
skip. TypeScript and production build passed; Go tests passed before the
frontend-only review amendments.
- Regression tests cover old saved plural targets, plural tool
arguments, same-name resources in different API groups, PodMetrics,
workload alerts, repeated-start identity, and an undiscovered irregular
CRD.
- Visual test skipped: no layout or new interaction changed;
history-label behavior is covered by unit tests.
0 commit comments