Auto E2E test run 2026-05-18

[ANcpLua]

Summary

First real E2E scenario landed on top of PR #347's bootstrap topology, plus
two pre-existing infrastructure bugs unblocked along the way. POST OTLP/HTTP
JSON to the running qyl-collector container, assert the ingest lands in
DuckDB and is reflected in /api/v1/telemetry/stats. Topology fixture
boots both qyl-collector and qyl-mcp end-to-end for the first time since
#347 wired it up.

Scenario

• Operator/service -> POSTs an OTLP/HTTP JSON trace with one span
  to qyl-collector (/v1/traces)
• Expected outcome: 202 Accepted on ingest, and the storage stats
  endpoint (/api/v1/telemetry/stats) reflects the span (spanCount
  increases, newestSpanTime >= the ingest timestamp)

One scenario per class, one [Fact] per class. Joins E2ECollection via
[Collection(E2ECollection.Name)] so the fixture is shared with future
scenarios.

Topology booted

• qyl-collector:latest (locally built from services/qyl.collector/Dockerfile)
• qyl-mcp:latest (locally built from services/qyl.mcp/Dockerfile)
• WireMock LLM stub on a random localhost port (configured in the fixture
  but not exercised by this scenario)
• Booted via: Testcontainers (ICompositeContainer-style — three containers
  on a fresh qyl-e2e-* Docker network per fixture lifetime). TUnit.Aspire
  not yet adopted in qyl.

Assertions

• Ingest HTTP response is exactly 202 Accepted
• /api/v1/telemetry/stats spanCount increases past the pre-ingest baseline
  within 15 s (bounded poll, 250 ms cadence)
• /api/v1/telemetry/stats newestSpanTime >= the test's start nano timestamp

Refactors for testability (separate commits)

• c2a4fd18 refactor(tests/e2e): make topology fixture actually boot collector + mcp — three fixes that the bootstrap PR (deps: bump MCP 1.2 -> 1.3 + e2e bootstrap #347) couldn't
  surface because the fixture itself was never executed:
  • Pass QYL_OTLP_AUTH_MODE=Unsecured to collector (default is ApiKey
    in Production and requires API key configuration; collector aborted
    on startup before this).
  • Pass ASPNETCORE_URLS=http://+:5200 to MCP (the Dockerfile hard-codes
    8080, so the previous WithPortBinding(5200, true) mapped to a port
    nothing served).
  • Wait on the real /alive health endpoint instead of "Now listening on:" log scrape.
  • Collapse the dual-ctor pattern in QylTopologyFixture to a single
    public ctor (xUnit v3 ICollectionFixture<T> requires exactly one).

Production fixes shipped (separate commit)

• bede0b1f fix(docker): bump .NET base images so SDK 10.0.300 actually builds — the pinned mcr.microsoft.com/dotnet/sdk:10.0@sha256:8a90a473...
  shipped SDK 10.0.203, but global.json requires 10.0.300 since PR deps: bump .NET SDK to 10.0.300 + ANcpLua MSBuild SDKs #346.
  Every nuke DockerImageBuild (and therefore the full compose stack and
  the E2E topology) was broken since deps: bump .NET SDK to 10.0.300 + ANcpLua MSBuild SDKs #346 merged — no CI job exercises
  DockerImageBuild, so the regression sat latent. Bumped sdk:10.0,
  aspnet:10.0, sdk:10.0-alpine, and runtime-deps:10.0-alpine to the
  current latest SHAs.
• Same commit pins qyl.mcp runtime stage to --platform=linux/amd64
  to match its -r linux-musl-x64 cross-compile target. arm64 dev hosts
  (Apple Silicon + OrbStack/Docker Desktop) previously couldn't run the
  image because runtime-deps resolved to arm64, producing
  ld-musl-x86_64.so.1 not found. No-op on amd64 hosts.

Production bug surfaced (NOT fixed here — separate concern)

GET /api/v1/traces is fully broken: schema declares
spans.kind VARCHAR NOT NULL and spans.status_code VARCHAR NOT NULL
(services/qyl.collector/Storage/DuckDbSchema.g.sql:316,319), but
SpanStorageRow.Kind and SpanStorageRow.StatusCode are byte. The
source-generated MapFromReader
(internal/qyl.collector.storage.generators/DuckDbEmitter.cs:219-222)
emits reader.Col(N).GetByte(0), so every span read throws
InvalidCastException: Unable to cast object of type 'System.String' to type 'System.Byte' and the endpoint returns 500.

Repro (against a fresh collector container with QYL_OTLP_AUTH_MODE=Unsecured):

curl -s -X POST http://localhost:5100/v1/traces \
  -H 'Content-Type: application/json' \
  -d '{"resourceSpans":[{"resource":{"attributes":[{"key":"service.name","value":{"stringValue":"x"}}]},"scopeSpans":[{"spans":[{"traceId":"abcdef0123456789abcdef0123456789","spanId":"abcdef0123456789","name":"s","kind":1,"startTimeUnixNano":1779000000000000000,"endTimeUnixNano":1779000000001000000,"status":{"code":1}}]}]}]}'
# 202 Accepted

curl -s http://localhost:5100/api/v1/traces?limit=10
# {"error":"Internal Server Error","traceId":"..."}

Fix is either schema migration to TINYINT (and similarly for
spans.kind) or property type change to string. NOT fixed in this PR
because (a) it's unrelated to E2E coverage, (b) a schema migration needs
its own focused PR with migration-up/down testing and the integration-test
suite extended, and (c) it's the higher-priority next-cycle item — the
routine handoff records this as gap #1.

This scenario asserts via /api/v1/telemetry/stats instead (which works
— it doesn't go through SpanStorageRow.MapFromReader), so the
end-to-end ingest pipeline is verified without depending on the broken
read path.

xUnit -> TUnit migrations

None. Repo standard is xUnit.v3 with xunit.v3.mtp-v2 (verified across
qyl.collector.tests, qyl.collector.integration.tests, qyl.mcp.tests,
and the existing qyl.e2e.tests bootstrap). New scenario matches the
existing style.

Runtime

• Setup (topology boot): ~4 s (collector ~3 s on /health, MCP ~2 s on /alive)
• Scenario: ~1 s (POST returns immediately, stats poll converges within ~500 ms)
• Teardown: ~0.3 s (containers + network deleted)
• Total per run: ~5-7 s

Stability check

4 consecutive local runs, all passed:

RUN 1: 6s 042ms  passed
RUN 2: 4s 810ms  passed
RUN 3: 4s 604ms  passed
RUN 4 (initial verification): 6s 193ms  passed

Zero flakes.

Mutation: not applicable at the E2E level.

Gaps remaining for next run

1. Fix the spans VARCHAR-vs-byte read-mapping bug (highest priority — a
   real production data-fetch defect, not an E2E concern). Once fixed,
   extend this scenario to also assert via GET /api/v1/traces/{traceId}
   for a true read+write roundtrip.
2. Second E2E scenario: MCP -> collector handshake. The MCP container
   now boots; drive an MCP tool that reads collector data (POST OTLP
   first, then invoke an MCP search tool over JSON-RPC, assert the span
   is returned).
3. Third E2E scenario: chat ingest -> trace at sink with credentials
   redacted — the original handoff candidate. Larger surface (needs a
   sink container plus LLM wiring); do after Add Claude Code GitHub Workflow #1 and refactor: internal OTLP types + remove ghost code #2.

🤖 Generated with Claude Code