Upstream workflows should disable observability when GH_AW_OTEL_* secrets are unset

[sg650]

Summary

An upstream workflow (copilot-token-audit) failed in a downstream repository because the workflow unconditionally configures OTEL observability, but the downstream repo does not define GH_AW_OTEL_ENDPOINT / GH_AW_OTEL_HEADERS secrets.

This causes the MCP Gateway to fail validation before the agent starts.

I think observability should be optional for reusable/upstream workflows: if the OTEL secrets are missing or empty, the workflow should still run and just skip telemetry.

Downstream repro

Repository: sixfiftylabs/app
Workflow: copilot-token-audit
Run: 25700340601
Trigger: workflow_dispatch

Workflow source includes:

observability:
  otlp:
    endpoint: ${{ secrets.GH_AW_OTEL_ENDPOINT }}
    headers: ${{ secrets.GH_AW_OTEL_HEADERS }}

The downstream repo does not have those secrets set.

Observed failure

From the MCP Gateway logs:

/gateway/opentelemetry/endpoint
Error: length must be >= 1, but got 0

/gateway/opentelemetry/headers
Error: does not match pattern

Expanded error:

failed to load config: Configuration validation error (MCP Gateway version: v0.3.6)
Location: /gateway/opentelemetry/endpoint
Error: length must be >= 1, but got 0
Location: /gateway/opentelemetry/headers
Error: does not match pattern

Because the gateway never starts, the agent does not run at all, so the workflow produces no normal analysis output.

Expected behavior

If OTEL secrets are unset or empty, gh-aw workflows should still run successfully with observability disabled.

In other words, this block should be treated as optional at runtime for downstream consumers:

• either omit gateway.opentelemetry entirely when the secrets are missing
• or have workflow authoring guidance / shared components that make OTEL conditional by default
• or make gateway handling of empty observability config more forgiving

Why this matters

For downstream repos using upstream gh-aw workflows, OTEL is operational telemetry, not the primary workflow output.

When observability is configured unconditionally:

• the workflow hard-fails before the agent starts
• safe outputs never run
• users lose the actual issue/report/recommendation output from the workflow
• consumers may incorrectly conclude OTEL secrets are required for basic workflow functionality

Suggested fix

Any of these would help:

1. Treat observability as optional in shared examples/upstream workflows.
2. Make observability.otlp conditional when secrets are unset.
3. Improve validation / runtime behavior so empty OTEL config disables telemetry instead of aborting the whole agent job.
4. Document clearly whether GH_AW_OTEL_ENDPOINT / GH_AW_OTEL_HEADERS are required or optional for end users.

Related

• [cli-tools-test] MCP Gateway startup failure: shared/observability-otlp.md sets opentelemetry.headers as string but schema requires object #25588
• [aw-failures] [aw] Fix aw-portfolio-yield: placeholder npm package + empty OTel endpoint break compile and runtime #31456

Those look related, but this report is specifically about the downstream consumer experience with an upstream-shipped workflow (copilot-token-audit) failing in a non-gh-aw repo when OTEL secrets are not configured.

[pelikhan]

Added a field to observabilty to control behavior of missing secrets.