fix: CLI, OTLP receiver, and diagnostics server bugs

[strawgate]

Summary

Seven bugs fixed in one conflict-free PR:

• generate-json prints NaN average for zero-line output #682 --generate-json 0 printed avg NaN bytes/line — zero-line case now prints a sensible message
• bug: --blackhole <invalid-addr> exits 0 despite printing an error #708 --blackhole notanaddr exited 0 — address now validated with parse::<SocketAddr>(), exits 1 on bad input
• blackhole CLI fails when port 9090 is already in use #681 --blackhole failed when port 9090 was already in use — diagnostics port now uses 0 (OS picks a free port)
• OTLP receiver accepts invalid /v1/logs* path prefixes #686 OTLP receiver accepted /v1/logsFOO, /v1/logs/extra etc. with 200 — only exact /v1/logs path is now accepted
• OTLP receiver treats JSON Content-Type matching as case-sensitive #687 OTLP Content-Type matching was case-sensitive — Application/JSON now treated as JSON per RFC 7231
• bug: diagnostics HTTP API accepts any HTTP method (POST, DELETE) on all routes — returns 200 #728 Diagnostics server returned 200 for POST/DELETE on all routes — non-GET requests now get 405 with Allow: GET
• bug: /metrics endpoint returns 404 — documented as available in CONFIG_REFERENCE #715 /metrics returned generic 404 with no explanation — now returns 410 Gone pointing to /api/pipelines

Test plan

• New unit tests for every fix (142 io tests — all green, up from 141)
• cargo clippy -- -D warnings clean
• cargo check --all-targets clean
• Pre-commit hook passes

🤖 Generated with Claude Code

[coderabbitai]

Warning

.coderabbit.yaml has a parsing error

The CodeRabbit configuration file in this repository has a parsing error and default settings were used instead. Please fix the error(s) in the configuration file. You can initialize chat with CodeRabbit to get help with the configuration file.

💥 Parsing errors (1)

Validation error: Instructions must be under 10000 characters at "reviews.pre_merge_checks.custom_checks[1].instructions"

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

This PR hardens HTTP endpoint validation across diagnostics and OTLP receiver services. Changes enforce HTTP method constraints—rejecting non-GET requests to diagnostics endpoints with 405 responses and non-POST requests to OTLP receiver with 405 responses. OTLP receiver routing switches from prefix matching to exact path matching for /v1/logs, returning 404 for mismatched paths. Content-Type detection becomes case-insensitive. Configuration validation improves via strict socket address parsing, and a division-by-zero edge case in log generation is fixed.

Possibly related PRs

• feat: replace --blackhole with pipeline-based OTLP receiver #635: Overlaps on OTLP receiver and diagnostics HTTP handling with shared focus on request routing validation and endpoint behavior constraints.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@crates/logfwd/src/main.rs`:
- Around line 230-232: The runtime prints a dashboard URL using
config.server.diagnostics verbatim which becomes useless when diagnostics was
set to ephemeral port 0 in the YAML; update the startup path that handles the
blackhole/diagnostics flow (where yaml is built and the dashboard URL is
printed) to either suppress printing the URL when config.server.diagnostics has
port 0 (i.e. detect ":0") or, preferable, after creating the tiny_http server,
call tiny_http::Server::server_addr() to get the actual bound address and
propagate that address into the value used for the printed dashboard URL so
users see the real host:port; change code around the yaml/config usage and the
dashboard print logic to use the resolved address when available.

🪄 Autofix (Beta)

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: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9d725bda-78fa-48d3-9363-9204d9e86640

📥 Commits

Reviewing files that changed from the base of the PR and between 8486bf8 and f4bf2f2.

📒 Files selected for processing (3)

• crates/logfwd-io/src/diagnostics.rs
• crates/logfwd-io/src/otlp_receiver.rs
• crates/logfwd/src/main.rs

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Ephemeral port prevents collisions but the printed dashboard URL becomes useless.

Using port 0 solves #681, but the dashboard URL printed at runtime (line 471) will show http://127.0.0.1:0 since config.server.diagnostics is used verbatim. Users won't know the actual listening port.

For --blackhole (testing/benchmarking), this may be acceptable, but consider either:

1. Suppressing the dashboard URL when using ephemeral ports, or
2. Retrieving the actual bound address from tiny_http::Server::server_addr() and propagating it

The current behavior is confusing but non-blocking for the blackhole's primary function.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/logfwd/src/main.rs` around lines 230 - 232, The runtime prints a
dashboard URL using config.server.diagnostics verbatim which becomes useless
when diagnostics was set to ephemeral port 0 in the YAML; update the startup
path that handles the blackhole/diagnostics flow (where yaml is built and the
dashboard URL is printed) to either suppress printing the URL when
config.server.diagnostics has port 0 (i.e. detect ":0") or, preferable, after
creating the tiny_http server, call tiny_http::Server::server_addr() to get the
actual bound address and propagate that address into the value used for the
printed dashboard URL so users see the real host:port; change code around the
yaml/config usage and the dashboard print logic to use the resolved address when
available.