Scope current MCP warning events to observed resource and Pod UIDs

[nadaverell]

After a resource is recreated with the same name, its old warning events can enter a current get_resource(include=events) or workload diagnose response. Match current warning evidence against the UID of the already-read raw object and the UIDs of Pods proven to belong to that current root. A shared cached ownership traversal verifies the root and each intermediate ReplicaSet or Job by API group, kind, name and UID before any Pod enters diagnosis. A known UID mismatch excludes a previous incarnation; UID-less events retain identity matching and do not prove an incarnation.

Both entry points reuse the existing warning filter. Exact API-group and scoped-namespace matching, warning-only selection, deduplication, caps and lister-error reporting remain intact. No extra resource fetches are needed. The existing name-based resolver remains available for consumers that have not read a root object; Diagnose uses the explicit incarnation-qualified API. FreeLens UID matching informed the baseline; its special Node UID=name behavior is deliberately not copied.

Scope: these current MCP evidence paths. get_events, resource history and timeline keep historical incarnations. UI, GitOps/Application event aggregation and a shared event-provenance model are separate surfaces. No public shape, package release or RBAC posture change.

Validation: focused filter and actual fake-informer/tool integration tests pass, including replacement root/Pod/intermediate-owner UIDs, group collisions, UID-less events and Node identity. Actual Diagnose integration rejects retained previous-root and replaced-ReplicaSet Pods; 100 hot ownership traversals perform zero Kubernetes object reads. The complete MCP suite, type check, full frontend/embed/backend build and root tests pass. Actual isolated-kind resources were created and recreated: get_resource and diagnose return only current-UID warnings, while get_events retains both incarnations. A retained real-UID previous-root ReplicaSet and Pod remain in the cache and historical event query but do not enter the current Deployment diagnosis.

---

Note

Medium Risk
Changes how diagnose resolves pods and filters events—core triage paths—but behavior is tightened with tests and does not alter RBAC or public API shapes.

Overview
Workload diagnose and get_resource(include=events) no longer surface warning events from a prior object with the same name. Evidence is tied to the UID of the resource already read and, for diagnose, to Pods resolved through a new UID-qualified ownership walk.

WorkloadPodsForUID walks Deployment/Rollout → ReplicaSet and CronJob → Job chains in the cache, matching group, kind, name, and UID at each hop via shared controllerMatchesIdentity. Diagnose pod resolution switches from name-only WorkloadPods to this API so replaced roots, stale ReplicaSets, and their Pods do not affect logs, metrics, or events. The name-based WorkloadPods API remains for callers without a current root object.

filterEventsByInvolvedObject now accepts the resource UID and a name→Pod UID map: a known involvedObject.uid mismatch drops a previous incarnation; UID-less events still match on kind/group/name. get_resource passes the fetched object’s UID and excludes workload Pod events; diagnose passes current pod UIDs. Docs note that get_events, history, and timeline stay historical.

^{Reviewed by Cursor Bugbot for commit 409ede9. Bugbot is set up for automated code reviews on this repo. Configure here.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Scope current MCP warnings to observed resource and Pod UIDs

🐞 Bug fix 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Exclude warnings from previous resource or Pod incarnations in current MCP evidence.
• Preserve UID-less warnings and historical event views without additional resource fetches.
• Add filter and fake-informer tests for replacement UIDs, API groups, and Node identity.

Diagram

graph TD
  Root["Observed resource"] --> Match{"Identity and UID"} --> Dedup["Warning dedup"] --> Current["Current MCP evidence"]
  Pods["Resolved Pods"] --> Match
  Lister["Scoped event lister"] --> Match
  Lister --> History["Historical events"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Query events by UID at the API

• ➕ Could narrow retrieved events before local filtering.
• ➖ Requires additional API queries rather than reusing cached events.
• ➖ Would need a separate path to retain UID-less, identity-matched warnings.

Recommendation: Keep the shared local filter: it uses UIDs already available to both entry points, preserves UID-less evidence, and leaves historical views unchanged without expanding API access.

Files changed (5) +145 / -37

Bug fix (2) +33 / -29

tools.goPass the observed resource UID to event extras +10/-4

Pass the observed resource UID to event extras

• Reads the already-fetched object's UID and passes it to the shared warning filter for get_resource(include=events). Supplemental event inclusion remains limited to the resource itself.

internal/mcp/tools.go

tools_diagnose.goFilter diagnose warnings by resource and Pod UIDs +23/-25

Filter diagnose warnings by resource and Pod UIDs

• Passes the observed resource UID and resolved Pod UIDs into the shared warning filter. Known UID mismatches are excluded; UID-less events remain eligible when kind, group, and name match.

internal/mcp/tools_diagnose.go

Tests (2) +110 / -8

events_tool_test.goTest incarnation-aware warning selection +109/-7

Test incarnation-aware warning selection

• Adds filter cases for replaced resources and Pods, UID-less events, API-group collisions, and Node UIDs. Exercises get_resource through a fake informer and checks resource-plus-Pod event selection through the shared fetch path.

internal/mcp/events_tool_test.go

tools_rollouts_test.goAdapt revisions test to the extras UID argument +1/-1

Adapt revisions test to the extras UID argument

• Updates the existing extras call to supply an empty UID; revision-include behavior is unchanged.

internal/mcp/tools_rollouts_test.go

Documentation (1) +2 / -0

mcp.mdDocument current-warning UID semantics +2/-0

Document current-warning UID semantics

• Explains that current MCP evidence excludes known UID mismatches while retaining UID-less warnings. Clarifies that historical event views are unaffected.

docs/mcp.md

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Old pod warnings appear in new diagnoses ✓ Resolved

Description

fetchEventsForResource treats every pod returned by WorkloadPods as current, but that resolver
matches controller kind and name without checking the already-read workload UID. If a workload is
recreated under the same name while old pods remain, their UIDs enter podUIDs, and warnings for
those old pods pass the new event UID check.

Code

internal/mcp/tools_diagnose.go[R887-890]

+	podUIDs := make(map[string]types.UID, len(pods))
  for _, p := range pods {
  	if p != nil {
-			podNames[p.Name] = true
+			podUIDs[p.Name] = p.UID

Evidence

WorkloadPods retains pods using name-based ownership predicates, including direct owners and
Deployment-to-ReplicaSet chains. The changed code copies every resulting pod UID into the accepted
map, and the event filter then accepts a warning whose UID matches that pod, even when the pod
belongs to an older same-name workload.

internal/k8s/workload_pods.go[38-55]
internal/k8s/workload_pods.go[95-123]
internal/mcp/tools_diagnose.go[887-893]
internal/mcp/tools_diagnose.go[1146-1150]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Workload diagnose can include old pod warnings after a same-name workload recreation because the resolved pod set is not qualified by the current workload UID.
## Fix Focus Areas
- internal/mcp/tools_diagnose.go[318-322]
- internal/mcp/tools_diagnose.go[887-893]
- internal/k8s/workload_pods.go[95-149]
## Recommended Fix
Resolve diagnose pods against the already-read workload UID before building `podUIDs`. Require direct owner UIDs to match the workload; for ownership chains, also verify each intermediate owner UID against its cached object and its root owner UID against the current workload.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can route each severity your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗