[Obs AI Assistant] Fix no-params log categories assertion after #290244

[kibanamachine]

Fixes #290494

Summary

• The API test returns no service summary and the service + container log categories when no params are specified asserted two log categories for a query with no entity params, but now receives [], so it fails deterministically on main.
• [Obs AI Assistant] Skip log rate analysis and log categories when no entity filters are present #290244 deliberately stopped fetching log categories (and log rate analysis) when the request carries no entity filters, so the old assertion expects data the product no longer promises.
• This corrects the stale assertion to toStrictEqual([]) and renames the test to returns no service summary and no log categories when no params are specified.

Relevant history

• [Obs AI Assistant] Skip log rate analysis and log categories when no entity filters are present #290244: wrapped both log data fetchers in if (hasEntityFilters) in get_observability_alert_details_context/index.ts, so an unscoped query ({}) never produces the logCategories item — turning the pre-existing assertion into a stale expectation.

Context

• The failed-test investigator's comment diagnosed the same root cause and proposed the same fix; this patch follows it. hasEntityFilters is serviceName || hostName || containerId || kubernetesPodName, all undefined for the no-params case, so getLogCategories() returns []. The three sibling tests each supply an entity param and remain unaffected.
• This is a correct-the-assertion fix, not a weakening: the product intentionally short-circuits the unscoped path (it was fanning out across all log sources and hanging), so there are legitimately no categories to assert.
• Failures were reported on kibana-on-merge - main for both local-serverless-observability_complete and local-stateful-classic targets; the run finished in 0.50s with an empty result rather than timing out, consistent with a deterministic contract change rather than a race.

Verification

Verified locally

• ✅ Passed: node scripts/eslint x-pack/solutions/observability/plugins/observability/test/scout/api/tests/alert_details_context_logs_with_service_name.spec.ts

Not verified locally

• This is a Scout API test that requires a live Elasticsearch + Kibana stack, which cannot be run in this environment.

Note

Share feedback in #kibana-qa. Mention @copilot to make quick changes.

Generated by Flaky Test Fixer for #290494 · claude · opus · 175.4 AIC · ⌖ 36 AIC · ⊞ 14.5K · ◷

[infra-vault-gh-plugin-prod]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!
• Click to trigger kibana-deploy-project-from-pr for this PR!
• Click to trigger kibana-deploy-cloud-from-pr for this PR!
• Click to trigger kibana-entity-store-performance-from-pr for this PR!
• Click to trigger kibana-storybooks-from-pr for this PR!

[kibanamachine]

⏭️ Flaky-fix verification skipped

The failing assertion is deterministic — corrected to match the contract change in #290244 — so required CI is the whole verdict and repeated flaky-runner passes would add no signal. Applied release_note:skip and backport:skip.

Why the flaky test runner wasn't used

The /flaky runner only adds signal when a fix mitigates a non-deterministic cause (a race, wait/timeout, ordering, or shared-state timing) whose stability must be confirmed across many runs. This PR corrects a stale assertion instead: after #290244 gated getLogCategories behind hasEntityFilters, an unscoped {} query deterministically returns [], so the old expectation (two log categories) failed 100% of the time on main, not flakily. A single required-CI pass is therefore a complete verdict.

How release-note and backport labels were chosen

Applied release_note:skip because the change only touches a Scout API test — no user-facing behavior changes.

• v9.5.4 → excluded; the 9.5 branch still fetches log categories unconditionally ([Obs AI Assistant] Skip log rate analysis and log categories when no entity filters are present #290244's hasEntityFilters gating is absent), so the original assertion is still correct there and this fix must not be backported.
• v9.4.7 → excluded; the 9.4 branch also lacks [Obs AI Assistant] Skip log rate analysis and log categories when no entity filters are present #290244's gating, so the same reasoning applies.
• v8.19.22 → excluded; [Obs AI Assistant] Skip log rate analysis and log categories when no entity filters are present #290244 is a main-only change absent from 9.5 and 9.4, so the older 8.19 branch cannot contain it either.

Generated by Flaky Fix Verifier for #290504 · claude · opus · 195.3 AIC · ⌖ 43.3 AIC · ⊞ 15.8K · ◷

[kibanamachine]

💔 Build Failed

• Buildkite Build
• Commit: 74f2054
• Build duration: 24 mins

Failed CI Steps

• Scout Lane #1 - stateful-classic / default
• Scout Lane #1 - stateful-classic / default
• Scout Lane #2 - serverless-observability_complete / default
• Scout Lane #2 - serverless-observability_complete / default

Metrics [docs]

✅ unchanged

Test Failures

• [job] [logs] Scout Lane #2 - serverless-observability_complete / default / local-serverless-observability_complete - Observability alert details context when logs are not annotated with service.name - returns a single log category when no params are specified
• [job] [logs] Scout Lane #2 - serverless-observability_complete / default / local-serverless-observability_complete - Observability alert details context when logs are not annotated with service.name - returns a single log category when no params are specified
• [job] [logs] Scout Lane #1 - stateful-classic / default / local-stateful-classic - Observability alert details context when logs are not annotated with service.name - returns a single log category when no params are specified
• [job] [logs] Scout Lane #1 - stateful-classic / default / local-stateful-classic - Observability alert details context when logs are not annotated with service.name - returns a single log category when no params are specified

History