Conversation
📝 WalkthroughWalkthroughThe PR adds a shared OTLP/HTTP span emitter, introduces an OpenObserve ingestion test, updates Vector relay testing, and upgrades OpenObserve tooling and deployment images to ChangesOpenObserve OTLP integration
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant IntegrationTest
participant OpenObserve
participant OtlpEmitter
participant TraceSearchAPI
IntegrationTest->>OpenObserve: start isolated instance
IntegrationTest->>OpenObserve: poll health endpoint
IntegrationTest->>OtlpEmitter: emit authenticated span
OtlpEmitter->>OpenObserve: send OTLP/HTTP span
IntegrationTest->>TraceSearchAPI: poll trace search
TraceSearchAPI-->>IntegrationTest: return span marker and service name
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
 |
|
Overall Grade |
Security Reliability Complexity Hygiene Coverage |
Code Review Summary
| Analyzer | Status | Updated (UTC) | Details |
|---|---|---|---|
| C# |  |
Aug 7, 2026 9:24a.m. | Review ↗ |
| C & C++ | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| Docker | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| Java | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| JavaScript | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| Python | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| Rust | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| Secrets | |
Aug 7, 2026 9:24a.m. | Review ↗ |
| Code coverage | |
Aug 7, 2026 10:00a.m. | Review ↗ |
Code Coverage Summary
| Language | Line Coverage (New Code) | Line Coverage (Overall) |
|---|---|---|
| Aggregate | 100% |
58.3% [▲ up 0.2% from main] |
| Python | - | 89.1% |
| Rust | 100% |
55.9% [▲ up 0.2% from main] |
➟ Additional coverage metrics may have been reported. See full coverage report ↗
Important
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 13 |
| Duplication | 2 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.mise/config.toml:
- Line 491: Update the OpenObserve image configuration around o2_image to define
an explicit healthcheck test using the pinned image and config/o2.env, matching
the native openobserve health behavior by checking /healthz rather than invoking
`/openobserve node status`. Ensure the generated Docker Compose healthcheck can
run directly in openobserve/openobserve:v0.91.5.
In `@libs/test-helpers/src/lib.rs`:
- Around line 88-90: Update the first documentation summary line for
drain_stderr to end with terminal punctuation, and add
libs/test-helpers/src/lib.rs to the sorted files allowlist in
doc-summary-ends-with-period.yaml.
In `@services/ws-wasi-runner/tests/vector_otlp_relay.rs`:
- Around line 99-101: Update emit_span to return the generated trace ID and span
ID, then capture both values at the call site in the test and compare them
directly with relayed.trace_id and relayed.span_id. Replace the non-empty
assertions while preserving the existing relay validation.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: a818b965-8296-4d08-b575-cbba929f1161
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (14)
.mise/config.tomlCargo.tomlconfig/ast-grep/rules/doc-summary-ends-with-period.yamlconfig/conftest/policy/mise/mise.regolibs/otlp-emit/Cargo.tomllibs/otlp-emit/src/lib.rslibs/test-helpers/src/lib.rsservices/ws-wasi-runner/Cargo.tomlservices/ws-wasi-runner/tests/o2_ingest_search.rsservices/ws-wasi-runner/tests/vector_otlp_relay.rsutilities/cli/src/deployment_types/docker_compose.rsutilities/cli/src/deployment_types/mise.rsverification/local/output/facility-security-scenario/compose.yamlverification/local/output/facility-security-scenario/mise.toml
💤 Files with no reviewable changes (1)
- config/conftest/policy/mise/mise.rego
| gh_http = "--http-url https://github.com --progress --ignore-existing" | ||
| # OpenObserve docker image for the openobserve/o2 dev-observability task. | ||
| o2_image = "openobserve/openobserve:v0.70.3" | ||
| o2_image = "openobserve/openobserve:v0.91.5" |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
image='openobserve/openobserve:v0.91.5'
name='o2-review-openobserve'
health_cmd='/openobserve node status'
trap 'docker rm -f "$name" >/dev/null 2>&1 || true' EXIT
docker pull "$image"
docker run --rm --env-file config/o2.env --entrypoint /openobserve "$image" node status
docker run --detach --name "$name" --env-file config/o2.env \
--publish 5080:5080 \
--health-cmd "$health_cmd" \
--health-interval 5s \
--health-timeout 3s \
--health-retries 20 \
--health-start-period 10s \
"$image" >/dev/null
for ((attempt = 0; attempt < 60; attempt += 1)); do
state="$(docker inspect --format '{{.State.Health.Status}}' "$name")"
[[ "$state" == healthy ]] && exit 0
sleep 1
done
echo "OpenObserve image did not become healthy" >&2
exit 1Repository: edge-toolkit/core
Length of output: 200
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "## .mise/config.toml relevant lines"
sed -n '480,500p' .mise/config.toml || true
echo
echo "## deployment docker image entries"
rg -n "openobserve/openobserve|o2_image|healthcheck|health" .mise/config.toml utilities/cli/src/deployment_types/docker_compose.rs services/ws-wasi-runner/tests/o2_ingest_search.rs || trueRepository: edge-toolkit/core
Length of output: 4137
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "## .mise/config.toml relevant lines:"
sed -n '480,500p' .mise/config.toml || true
echo
echo "## deployment docker image entries:"
rg -n "openobserve/openobserve|o2_image|healthcheck|health" .mise/config.toml utilities/cli/src/deployment_types/docker_compose.rs services/ws-wasi-runner/tests/o2_ingest_search.rs || trueRepository: edge-toolkit/core
Length of output: 4139
🌐 Web query:
openobserve/openobserve:v0.91.5 Dockerfile healthcheck /openobserve node status
💡 Result:
In OpenObserve v0.91.5, the official endpoint for system health checks is /healthz [1][2]. This endpoint performs a basic liveness check, returning a JSON response indicating the status, typically {"status": "ok"} [1][3][4]. Regarding Docker health checks, the standard OpenObserve Docker image (based on debian:trixie-slim) does not include curl or other command-line utilities by default [5][6]. Consequently, if you attempt to define a Docker HEALTHCHECK using curl inside the standard container, it will fail with an error stating the executable is not found [5]. To implement a health check in Docker for OpenObserve, you have two primary options: 1. Use a Debug Image: Use a -debug version of the OpenObserve image (e.g., openobserve/openobserve:v0.91.5-debug), which includes tools like curl [5][7]. 2. External Health Checking: Perform the health check from outside the container (e.g., via a sidecar or orchestration platform like Kubernetes or Docker Compose) to avoid relying on shell utilities inside the runtime container [5]. For cluster environments, OpenObserve also utilizes a /schedulez endpoint to check node availability for task scheduling [1][8][4]. This endpoint verifies if a node is both online and enabled for task scheduling, returning a 200 OK status only if the node is actively available for workload distribution [1][4]. Internal cluster management uses these health checks to proactively remove unresponsive nodes from the consistent hash ring [9].
Citations:
- 1: https://github.com/openobserve/openobserve/blob/ada8b376/src/handler/http/request/status/mod.rs
- 2: https://deepwiki.com/openobserve/openobserve/3.2-http-and-grpc-api-layer
- 3: https://apis.io/apis/openobserve/openobserve-meta-api/
- 4: https://github.com/openobserve/openobserve/blob/a3e01f18/src/handler/http/request/status/mod.rs
- 5: Health check openobserve/openobserve#6561
- 6: https://github.com/openobserve/openobserve/blob/b9e79ed4/deploy/build/Dockerfile
- 7: https://hub.docker.com/r/openobserve/openobserve/tags
- 8: https://github.com/openobserve/openobserve/blob/26bc1c4b/src/handler/http/request/status/mod.rs
- 9: fix: node health api openobserve/openobserve#8744
🌐 Web query:
openobserve v0.91.5 /openobserve node status command
💡 Result:
In OpenObserve v0.91.5, there is no direct command-line interface (CLI) command named "node status" within the primary openobserve binary or the o2 CLI [1][2][3][4]. Monitoring node health and status in OpenObserve is primarily handled through the following methods: 1. Web UI: You can monitor node health directly in the OpenObserve dashboard by navigating to the node management section [5]. This provides status indicators (Online, Prepare, Offline) along with metrics such as CPU usage, memory usage, and TCP connections [5]. 2. Internal API: The OpenObserve codebase includes internal logic for node status reporting (e.g., /node/status endpoints) [6][7], but these are intended for system-level communication rather than direct user-invoked CLI commands. 3. O2 CLI: The o2 CLI is the designated tool for imperative management of OpenObserve resources, but its commands are focused on managing entities like organizations, dashboards, alerts, and templates rather than low-level node health status [1][2]. If you are attempting to check cluster or node status, ensure you are using the Web UI's administration interface, which is the documented and supported method for monitoring node health and infrastructure performance [5].
Citations:
- 1: https://openobserve.ai/docs/administration/configuration/o2-cli/o2-cli/
- 2: https://github.com/openobserve/o2-cli
- 3: https://github.com/openobserve/openobserve/blob/ab863916/src/cli/basic/cli.rs
- 4: https://github.com/openobserve/openobserve/blob/ada8b376/src/cli/basic/cli.rs
- 5: https://openobserve.ai/docs/user-guide/account-administration/management/nodes/
- 6: https://github.com/openobserve/openobserve/blob/ada8b376/src/cli/basic/http.rs
- 7: https://github.com/openobserve/openobserve/blob/ada8b376/src/handler/http/request/status/mod.rs
🌐 Web query:
site:github.com/openobserve/openobserve "node status" "/openobserve" v0.91.5
💡 Result:
As of August 7, 2026, there is no official release versioned "v0.91.5" for OpenObserve [1]. The OpenObserve release history shows that the 0.91.x branch progressed through v0.91.3 [2], which was published on July 21, 2026 [2]. Subsequent development activity has moved toward the 0.92.0 release cycle [3]. Regarding node status functionality in OpenObserve: 1. API Endpoint: OpenObserve provides a /node/status API endpoint [4]. This endpoint exposes detailed internal node metrics, including cache information such as the parquet metadata cache size [4]. 2. CLI Command: Users can access this information via the CLI using the command openobserve node status [4]. This command invokes the /node/status API and displays the retrieved information in a formatted, human-readable table [4][5]. 3. Health Monitoring: Separate from general status reporting, the system includes health check mechanisms (such as /healthz and /schedulez) to monitor node connectivity, operational status, and scheduling availability for cluster management [6][7]. For the most current information or to confirm if a specific fix or feature was backported to a version matching your requirements, it is recommended to check the official OpenObserve GitHub releases page [1].
Citations:
- 1: https://github.com/openobserve/openobserve/releases
- 2: https://github.com/openobserve/openobserve/releases/tag/v0.91.3
- 3: https://github.com/openobserve/openobserve/releases/tag/v0.92.0-rc1
- 4: feat: add parquet cache size in status openobserve/openobserve#7929
- 5: https://github.com/openobserve/openobserve/blob/ada8b376/src/cli/basic/http.rs
- 6: fix: node health api openobserve/openobserve#8744
- 7: https://github.com/openobserve/openobserve/blob/ada8b376/src/handler/http/request/status/mod.rs
🌐 Web query:
OpenObserve v0.91.5 Dockerfile HEALTHCHECK curl openobserve/node/status
💡 Result:
In OpenObserve, the correct endpoint for health checks is /healthz, not /node/status [1][2][3]. The standard OpenObserve Docker image is built from a slim Debian base, which does not include the curl utility [4][5][1]. Consequently, attempting to use curl in a HEALTHCHECK instruction will fail with an OCI runtime error unless the image is customized or a debug image is used [1]. To implement a health check for OpenObserve: 1. Use the /healthz endpoint, which returns a 200 OK status with {"status": "ok"} when the service is running [2][3]. 2. Because the standard production image lacks curl, you have two primary options: - Use a debug variant of the image (e.g., openobserve/openobserve:v0.91.5-debug), which includes tools like curl [1][6]. - If using the standard image, you must either install curl via a custom Dockerfile (e.g., RUN apt-get update && apt-get install -y curl) or implement the health check using available shell built-ins if possible, though installing curl is the standard approach for this requirement [1]. Example of a working HEALTHCHECK configuration (assuming curl is present): HEALTHCHECK --interval=5s --timeout=5s --retries=5 CMD curl --fail http://localhost:5080/healthz || exit 1 [1]
Citations:
- 1: Health check openobserve/openobserve#6561
- 2: https://github.com/openobserve/openobserve/blob/ada8b376/src/handler/http/request/status/mod.rs
- 3: https://apis.io/apis/openobserve/openobserve-meta-api/
- 4: https://github.com/openobserve/openobserve/blob/b9e79ed4/deploy/build/Dockerfile
- 5: https://github.com/openobserve/openobserve/blob/ab863916/deploy/build/Dockerfile
- 6: https://hub.docker.com/r/openobserve/openobserve
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "## docker_compose.rs OpenObserve service definition"
sed -n '1,50p' utilities/cli/src/deployment_types/docker_compose.rs || true
echo
echo "## o2_ingest_search.rs binary command and health wait"
sed -n '1,130p' services/ws-wasi-runner/tests/o2_ingest_search.rs || trueRepository: edge-toolkit/core
Length of output: 9018
Use a healthcheck that the OpenObserve image can run.
The generated healthcheck uses CMD /openobserve node status, but the native openobserve test starts the local Command::new("openobserve") binary separately and waits on /healthz. If openobserve/openobserve:v0.91.5 does not support this CLI node-status command, the generated Docker Compose service can fail Docker health checks immediately after startup. Make the image-level healthcheck contract an explicit test with the pinned image and config/o2.env.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.mise/config.toml at line 491, Update the OpenObserve image configuration
around o2_image to define an explicit healthcheck test using the pinned image
and config/o2.env, matching the native openobserve health behavior by checking
/healthz rather than invoking `/openobserve node status`. Ensure the generated
Docker Compose healthcheck can run directly in openobserve/openobserve:v0.91.5.
| /// The buffer is populated once the child's stderr reaches EOF (i.e. it exits), so read it after shutting | ||
| /// the child down. The child must have been spawned with `Stdio::piped()` on stderr. Use this for daemons | ||
| /// that log to stderr (e.g. vector); use [`drain_stdout`] for those that log to stdout (e.g. openobserve). |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
End the first doc-summary line with terminal punctuation.
Line 88 is the first /// line in this doc block. The configured rule flags it because it does not end with terminal punctuation.
Proposed fix
-/// The buffer is populated once the child's stderr reaches EOF (i.e. it exits), so read it after shutting
-/// the child down. The child must have been spawned with `Stdio::piped()` on stderr. Use this for daemons
+/// The buffer is populated when the child's stderr reaches EOF.
+///
+/// Read it after shutting the child down. The child must have been spawned with `Stdio::piped()` on stderr.
+/// Use this for daemonsAs per coding guidelines, "Whenever modifying a Rust file, add it to the sorted files: allowlist of doc-summary-ends-with-period.yaml and fix first-line doc-summary violations."
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| /// The buffer is populated once the child's stderr reaches EOF (i.e. it exits), so read it after shutting | |
| /// the child down. The child must have been spawned with `Stdio::piped()` on stderr. Use this for daemons | |
| /// that log to stderr (e.g. vector); use [`drain_stdout`] for those that log to stdout (e.g. openobserve). | |
| /// The buffer is populated when the child's stderr reaches EOF. | |
| /// | |
| /// Read it after shutting the child down. The child must have been spawned with `Stdio::piped()` on stderr. | |
| /// Use this for daemons | |
| /// that log to stderr (e.g. vector); use [`drain_stdout`] for those that log to stdout (e.g. openobserve). |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@libs/test-helpers/src/lib.rs` around lines 88 - 90, Update the first
documentation summary line for drain_stderr to end with terminal punctuation,
and add libs/test-helpers/src/lib.rs to the sorted files allowlist in
doc-summary-ends-with-period.yaml.
Source: Coding guidelines
| // The SDK generates the ids, so we can't assert exact values -- but a relayed span must carry both. | ||
| assert!(!relayed.trace_id.is_empty(), "relayed span is missing its trace id"); | ||
| assert!(!relayed.span_id.is_empty(), "relayed span is missing its span id"); |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
mise exec -- ast-grep outline libs/otlp-emit/src/lib.rs --items all
mise exec -- rg -n -C 4 'emit_span|span_context|trace_id|span_id' \
libs/otlp-emit/src/lib.rs \
services/ws-wasi-runner/tests/vector_otlp_relay.rs \
services/ws-wasi-runner/tests/o2_ingest_search.rsRepository: edge-toolkit/core
Length of output: 197
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf 'Repository files relevant:\n'
git ls-files | rg '(^|/)libs/otlp-emit/src/lib\.rs$|services/ws-wasi-runner/tests/(vector_otlp_relay|o2_ingest_search)\.rs$' || true
printf '\nRelevant symbol/code searches:\n'
rg -n -C 5 'emit_span|struct .*Emitter|trace_id|span_id|span_context|Otlp|OtlpEmitter|Tracer|ActiveSpan' \
libs/otlp-emit/src/lib.rs \
services/ws-wasi-runner/tests/vector_otlp_relay.rs \
services/ws-wasi-runner/tests/o2_ingest_search.rs \
2>/dev/null || true
printf '\nFile line counts:\n'
wc -l libs/otlp-emit/src/lib.rs services/ws-wasi-runner/tests/vector_otlp_relay.rs services/ws-wasi-runner/tests/o2_ingest_search.rs 2>/dev/null || trueRepository: edge-toolkit/core
Length of output: 7573
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf 'libs/otlp-emit/src/lib.rs:\n'
cat -n libs/otlp-emit/src/lib.rs
printf '\nservices/ws-wasi-runner/tests/vector_otlp_relay.rs context:\n'
cat -n services/ws-wasi-runner/tests/vector_otlp_relay.rs | sed -n '1,130p'
printf '\nmanifest references opentelemetry crates:\n'
rg -n 'opentelemetry|opentelemetry_otlp|opentelemetry_sdk|otlp-emit' Cargo.toml Cargo.lock --glob 'Cargo.lock' --glob 'Cargo.toml' 2>/dev/null || trueRepository: edge-toolkit/core
Length of output: 13707
Compare the relayed trace/span IDs with the emitted IDs.
emit_span currently does not return the generated IDs, while these checks only require non-empty received IDs. Return the emitter’s trace ID and span ID and assert they match relayed.trace_id and relayed.span_id so the relay cannot replace IDs without failing.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@services/ws-wasi-runner/tests/vector_otlp_relay.rs` around lines 99 - 101,
Update emit_span to return the generated trace ID and span ID, then capture both
values at the call site in the test and compare them directly with
relayed.trace_id and relayed.span_id. Replace the non-empty assertions while
preserving the existing relay validation.
2 participants
Summary by CodeRabbit
New Features
.zippackage.Improvements