mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-04 16:09:05 +00:00
Vamsi Karthik RandClaude Opus 4.8
96bbed8a6e
## What Follow-up to #13209. In the full-suite alpha1 CI (runs 29576418415 → 29655287388) the **Alerts** shard was failing on two independent issues. This PR makes both deterministic so the shard goes green. Test-infra / page-object only — **no product code**. ✅ Green: alpha1-e2e / Alerts — 20 passed, 4 flaky (recovered on retry), 3 skipped, 0 failures https://github.com/openobserve/o2-enterprise/actions/runs/29655287388/job/88116296475 ## Root cause & fixes ### 1) `alerts-ui-operations:191` — empty-name validation assertion **Root cause:** the check asserted an inline field-error element (`add-alert-name-input-error`) that isn't reliably rendered for the topbar name input, so the assertion timed out even though the empty-name Save is correctly blocked. Verified against alpha with a live session: on empty-name Save the app surfaces the block as a **toast — "Alert name is required."** **Fix:** assert the toast (the app's actual, visible signal), keeping the inline field error as an `.or()` fallback so the check stays robust regardless of which surface renders. Validated locally against alpha (PASS) and green in CI. ### 2) `alerts-e2e-flow:106/160` + `alerts-import:52/165` — self-seeded stream registration **Root cause:** these specs seed a unique per-test stream (`alert_e2e_*` / `alert_import_*`) with custom columns, then wait for it to register in `GET /api/{org}/streams?type=logs` before opening the wizard. On the shared cloud alpha org under full multi-shard concurrency, that registration **intermittently takes minutes, not ~1s**, to reflect in the list — reproduced with both Playwright `page.request` and a raw HTTP client, so it is **not** a test-auth issue. The wizard's stream dropdown reads the same list, so the stream is absent there too. The old poll waited only 15/60s and **threw**, hard-failing in `beforeEach`. **Fix:** widen the registration poll to **90s** (matches global-setup's indexing budget) and make it **non-fatal** — warn and proceed instead of throwing. The stream is already ingested, and the point-of-use dropdown selection already retries (in-place ×4 + wizard re-entry ×2); with `retries: 2` those slow-to-register streams now recover as *flaky* rather than hard-fail. In the green run, 6 streams hit the 90s warning and all recovered. ## Known follow-up (infra, not test-fixable here) The deeper cause of the stream flakes is a **server-side streams-list propagation lag with session-sticky routing** on the shared cloud alpha org — a freshly-ingested stream can take minutes to appear in `/streams` for a given session (some sessions land on a stale node). No test-side wait fully resolves it; the retries absorb it. Flagged for infra investigation. ## Scope / safety - 2 files: `pages/commonActions.js`, `pages/alertsPages/alertsPage.js`. No product code. - No tests added/deleted/skipped, no `.only`, no assertions weakened (191 asserts the real user-facing signal; the `.or()` keeps inline-error coverage). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>