mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-05 00:09:35 +00:00
Loakesh Indiran
cca95a9ec6
## Problem A failing HTTP check showed **Failed** at the top of the run detail and **Assertions: Passed** below it — a green tick against `status_code eq 200` on a run that never got a status code. The probe is right to omit `assertions_passed` when the request never returned a response (connection refused, EOF, timeout): it returns before evaluating anything, because there is nothing to assert against. The view had two branches for three states: ```vue :variant="run.assertionsPassed === false ? 'error' : 'success'" ``` `null` is not `false`, so "never ran" landed in the success branch. | `assertions_passed` | means | UI showed | |---|---|---| | `true` | ran, all passed | Passed ✅ | | `false` | ran, one failed | Failed ✅ | | *absent* | never ran | Passed ❌ | ## Changes 1. **Three states, not two.** Absent renders as a neutral **Not evaluated** badge with neutral rows and a line explaining why. 2. **Render the probe's per-assertion results** when the record carries them (see synthetic-o2-agent#4), so a run with several failing assertions shows each one with its own comparison string instead of a single inferred red row. Records written before the probe echoed that array keep the old inference path. 3. **Fix `response_time_ms` on the legacy path.** The probe's detail leads with `response_time`, so `startsWith` never matched the configured field name and a failing latency assertion left every row green. The two renamed fields now go through a lookup map rather than one special case. 4. Reported rows are self-describing, so the assertions card no longer depends on the check-config fetch succeeding (403 on community builds, deleted check, …). ## Testing `ProtocolRunSummary.spec.ts` — 7 new tests covering the not-evaluated state, the still-passes case, the reported-array path, config-fetch failure, the legacy single-failure record, and `response_time_ms`. Full synthetics sweep: 499 passed, 0 failed. Verified end to end against a local deployment with five checks covering each case: | Check | Assertions | Record | UI | |---|---|---|---| | AT-A | `status_code eq 200` | `assertions_passed: true` | Passed, row green | | AT-B | `status_code eq 999` | `false` + array | Failed, row red | | AT-C | `status_code eq 999` + `body contains NOPE` | `false` + array of 2 | Failed, **both** rows red | | AT-D | `response_time_ms lt 1` | `false` + array | Failed, row red | | AT-E | unreachable target | `assertions_passed` absent | **Not evaluated** | Before: AT-C showed one red row and one green, AT-D showed no red row, AT-E showed Passed.
web
This template should help get you started developing with Vue 3 in Vite.
Recommended IDE Setup
VSCode + Volar (and disable Vetur) + TypeScript Vue Plugin (Volar).
Type Support for .vue Imports in TS
TypeScript cannot handle type information for .vue imports by default, so we replace the tsc CLI with vue-tsc for type checking. In editors, we need TypeScript Vue Plugin (Volar) to make the TypeScript language service aware of .vue types.
If the standalone TypeScript plugin doesn't feel fast enough to you, Volar has also implemented a Take Over Mode that is more performant. You can enable it by the following steps:
- Disable the built-in TypeScript Extension
- Run
Extensions: Show Built-in Extensionsfrom VSCode's command palette - Find
TypeScript and JavaScript Language Features, right click and selectDisable (Workspace)
- Run
- Reload the VSCode window by running
Developer: Reload Windowfrom the command palette.
Customize configuration
See Vite Configuration Reference.
Project Setup
npm install
Compile and Hot-Reload for Development
For stand-alone UI development environment, create .env file and which contains below environment variable
VITE_OPENOBSERVE_ENDPOINT=http://localhost:5080/
npm run dev
Type-Check, Compile and Minify for Production
npm run build
Run Unit Tests with Vitest
npm run test:unit
Run End-to-End Tests with Cypress
npm run test:e2e:dev
This runs the end-to-end tests against the Vite development server. It is much faster than the production build.
But it's still recommended to test the production build with test:e2e before deploying (e.g. in CI environments):
npm run build
npm run test:e2e
Lint with ESLint
npm run lint