docs/test: OpenTelemetry endpoint examples must be base URLs, and add an exporter URI test

Open
  • Is something wrong?
#357 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
73/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
documentation, testing

Research direction

Search for /v1/logs in docs/DEPLOYMENT.md, docs/superpowers/specs/2026-05-12-portainer-gitops-deployment-design.md and docs/GETTING_STARTED.md. Then read TaskFlow.Api/Extensions/OpenTelemetryServiceExtensions.cs and the existing OpenTelemetryServiceExtensionsTests to find how exporter options are resolved and tested. Done means the docs use base URLs, the test verifies all three signal URIs without doubled segments, and dotnet test and dotnet format --verify-no-changes pass.

Written by the indexing model from the issue text.

Description

bug docker

Groomed 2026-10-30, updated after splitting — ready for implementation.

The production fix (the taskflow-deploy value and redeploy) moved to #371, together with #358. This issue now covers only the docs and the test in this repo. It does not depend on what the live check in #371 finds.

Original Description

Problem

The production compose file in nevridge/taskflow-deploy sets:

OpenTelemetry__Endpoint=http://seq:5341/ingest/otlp/v1/logs

But TaskFlow.Api/Extensions/OpenTelemetryServiceExtensions.cs treats OpenTelemetry:Endpoint as a base URL and appends the signal path itself:

  • line 46: baseEndpoint + "/v1/traces"
  • line 58: baseEndpoint + "/v1/metrics"
  • line 99: baseEndpoint + "/v1/logs"

With the deploy value, logs would go to .../ingest/otlp/v1/logs/v1/logs, and traces and metrics to .../v1/logs/v1/traces and .../v1/logs/v1/metrics. Dev uses the base form http://seq:5341/ingest/otlp, which is what the code expects.

Status

Found by code reading and by comparing against a local clone of the deploy repo, which may be stale. The live deploy repo was read on 2026-10-30 and confirms the value above (images at sha-5405774). Not verified against live Seq. The same /v1/logs suffix also appears in docs/DEPLOYMENT.md (line 270 on main at 5405774) and docs/superpowers/specs/2026-05-12-portainer-gitops-deployment-design.md (line 90).

Suggested fix
  1. Confirm against the live deploy repo and live Seq whether production logs, traces and metrics are arriving. (Now #371.)
  2. If broken, change the deploy repo value to the base form http://seq:5341/ingest/otlp. (Now #371.)
  3. Correct the /v1/logs examples in docs/DEPLOYMENT.md and the GitOps design spec.
Context

Surfaced while grooming #203 (stale docker-compose.prod.yml), which deliberately leaves the deploy repo out of scope.

User Story

As a TaskFlow developer or operator following the docs, I want every documented OpenTelemetry__Endpoint example to be the base-URL form the API expects, and a test that proves the exporter URIs are built from it, so that a setup copied from the docs works and the path handling cannot regress unnoticed.

Acceptance Criteria

  1. Given docs/DEPLOYMENT.md (around line 270) and docs/superpowers/specs/2026-05-12-portainer-gitops-deployment-design.md (around line 90), when the change is merged, then neither shows an OpenTelemetry__Endpoint value ending in /v1/logs. Both show http://seq:5341/ingest/otlp.
  2. Given the docs describe OpenTelemetry:Endpoint, when they are searched, then each example is a base URL with no signal path, matching README.md, docs/LOGGING.md and docs/DOCKER_CONFIGURATION.md.
  3. Given docs/GETTING_STARTED.md (about line 238) shows a gRPC-style port 4317 example (http://your-otlp-backend:4317), when the change is merged, then the example uses a base-URL form consistent with the http/protobuf-only setting.
  4. Given a test configures OpenTelemetry:Endpoint as http://host:5341/ingest/otlp, when the exporter options are resolved, then the log, trace and metric exporter URIs end in /v1/logs, /v1/traces and /v1/metrics respectively, with no doubled segment. Existing tests only check registration, so this test is new. A trailing slash on the configured value (.../otlp/) gives the same URIs.
  5. Given the finished change, when I run dotnet test and dotnet format --verify-no-changes, then both pass, and backend line coverage stays at 75% or above.

Edge Cases

  • docs/GETTING_STARTED.md:238 and the existing OpenTelemetryServiceExtensionsTests use http://localhost:4317, a gRPC-style port. The API supports only http/protobuf. The new test uses the Seq-style base URL.
  • An empty-string OpenTelemetry__Endpoint bypasses the ?? fallback and throws at startup (new Uri("/v1/logs")). That is a separate failure mode and is not changed here.
  • A value that already ends in a signal path is not handled by the API. A startup guard is a possible follow-up issue, not part of this one.
  • Line numbers drift; find the examples by searching for /v1/logs.

Out of Scope

  • Changing the deploy repo, redeploying, or checking live Seq (#371).
  • ALLOWED_HOSTS (#358, folded into #371).
  • Making the API accept, auto-correct or reject endpoints that already include a signal path.
  • Adding gRPC or other OTLP protocol support.
  • Updating docker-compose.prod.yml, which has no OTel variables.
  • Restructuring Seq, dashboards or alerts.
Dominant language
C#
Stars
1
Forks
0
Avg merge
2h 2m
Merged PRs (30d)
98

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nevridge/TaskFlow

All issues in nevridge/TaskFlow

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.