Greptile Summary

This PR enriches the RCA prompt builder to surface richer Performance Insights evidence for the bad-query CPU saturation scenario: it adds support for fixture-native field names (statement, db_load_avg, nested wait_events, top_wait_events, top_users, top_hosts), labels PI-sourced Grafana log entries as "Performance Insights", and adds a new LLM directive to name the exact SQL and rule out connection exhaustion. Three focused unit tests cover the new rendering paths. All changes are additive and scoped to evidence formatting, with no changes to scoring or graph logic.

Confidence Score: 4/5

Safe to merge; only P2 style concerns remain.

All findings are P2 (raw source_type passthrough and a minor test coverage gap). No logic bugs or security issues were found. The new helpers are well-typed and the core formatting changes are correct.

No files require special attention; the source_type mapping in _format_grafana_log_entry is worth revisiting if new source types are added.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Grafana log entry] --> B{isinstance dict?}
    B -- No --> C[str truncated to 300]
    B -- Yes --> D[extract message, source_type, source_identifier]
    D --> E{source_type == aws_performance_insights?}
    E -- Yes --> F[relabel as Performance Insights]
    E -- No --> G[keep raw source_type]
    F --> H[join source parts]
    G --> H
    H --> I{source non-empty?}
    I -- No --> J[return message only]
    I -- Yes --> K[return source + message]

    subgraph PI[Performance Insights Section]
        L[top_sql items] --> M[sql = sql or statement]
        M --> N[db_load = db_load or db_load_avg]
        N --> O[render wait_events inline via _format_wait_events]
        P[wait_events or top_wait_events] --> Q[Top Wait Events block]
        R[top_users] --> S[Top Users block]
        T[top_hosts] --> U[Top Hosts block]
    end

_{Reviews (1): Last reviewed commit: "test(rca): cover performance insights pr..." | Re-trigger Greptile}

Thanks @sundaram2021.

Ran this locally.

Validation:

• pytest tests\nodes\root_cause_diagnosis -q → all passing
• synthetic: 004-cpu-saturation-bad-query → passed

I also validated against main: the scenario already passes on main, so this is not addressing a failing case. The change is primarily improving prompt construction and evidence clarity.

Overall, I agree with the direction. Making Performance Insights evidence more explicit (statement/db_load/wait_events, etc.) and reinforcing the exact-SQL + connection-exhaustion rule-out guidance should reduce variance and make the RCA reasoning more deterministic across providers.

Greptile’s comments are valid and worth addressing as follow-ups:

• _format_grafana_log_entry: avoid leaking raw source_type values into the prompt; a mapping or safe fallback would keep the prompt cleaner
• add minimal coverage for the grafana_error_logs branch since it shares the same formatter.

thanks for testing this out @cerencamkiran .
I was just waiting for testing , I'm resolving the greptile comments now ....

CI is failing becuase of some missing configuration in api keys

@muddlebee can look into it .

@sundaram2021 Merge/rebase latest main into your PR branch

@sundaram2021 Merge/rebase latest main into your PR branch

done

hey @rrajan94 can you please review this once , its all tested and everything passes successfully .
thanks :))

Tested locally:

• test_prompt_builder.py passes
• 004-cpu-saturation-bad-query now correctly surfaces the exact SQL, db_load / wait events, and rules out connection exhaustion
• also checked another scenario to ensure the stronger bad-query guidance does not regress the CPU red-herring case

This looks like a solid improvement to the evidence rendering / diagnosis prompt layer.

One small robustness nit: in the top wait events section, we still read the wait name with item.get("name", "unknown"), while _format_wait_events() supports both name and wait_event. If Performance Insights fixtures can emit wait_event there as well, it may be worth using the same fallback to avoid rendering unknown.

Good work @sundaram2021

Tested locally:

• test_prompt_builder.py passes
• 004-cpu-saturation-bad-query now correctly surfaces the exact SQL, db_load / wait events, and rules out connection exhaustion
• also checked another scenario to ensure the stronger bad-query guidance does not regress the CPU red-herring case

This looks like a solid improvement to the evidence rendering / diagnosis prompt layer.

One small robustness nit: in the top wait events section, we still read the wait name with item.get("name", "unknown"), while _format_wait_events() supports both name and wait_event. If Performance Insights fixtures can emit wait_event there as well, it may be worth using the same fallback to avoid rendering unknown.

Good work @sundaram2021

followed the convention .... I thought of changing it but it will add inconsistency, if tests have not passed then it would be worth changing but I think its okay for now

🤖 CI passed. Linter didn't scream. Reviewer typed LGTM. @sundaram2021, every machine in this pipeline just slow-clapped. 🖥️✨

👋 Join us on Discord - OpenSRE : hang out, contribute, or hunt for features and issues. Everyone's welcome.