jaegertracing/jaeger

Problem The ClickHouse spans table (internal/storage/v2/clickhouse/sql/create_spans_table.sql) stores nearly every OTLP span field, but the writer (dbmodel/to.go) and reader (dbmodel/from.go) have no column for these, so a span written to ClickHouse and read back loses them: OTLP field Level schema_url resource schema_url scope flags span dropped_attributes_count span, event, link, scope dropped_events_count span dropped_links_count span flags link The two schema_url fields matter beyond fidelity: RFC 0005 lists resource.schemaURL and scope.schemaURL as built-in filter fields, and ClickHouse is the only backend that declares all five levels, so these are the only two RFC 0005 built-in fields whose absence is a schema gap rather than unfinished lowering (#9701 maps five fields and can add the rest from existing columns). The dropped counts and flags carry no filter use, but a round trip through storage should not silently zero them, and the v1 storage integration s

Summary A Jaeger trace ID has two textual forms. The legacy model's model.TraceID.String() prints 16 hex characters when the high 64 bits are zero and 32 otherwise, while pcommon.TraceID.String() always prints 32. Every storage writer goes through pdata and writes 32 characters, so the short form never reaches storage anymore. It survives in the api v1 UI JSON that the query service still emits, in lenient ID parsers on the API input paths, in read-side padding that no writer needs, and in one byte-handling bug. This issue proposes to settle on the 32-character form everywhere and to remove the per-site workarounds, as a series of small independent PRs. Where the short form still appears API output. The api v1 UI JSON converter prints model.TraceID.String(), so every trace with a zero high half is shown to the UI and to the anonymizer with 16 characters [1]. API input. The api_v3 HTTP gateway and gRPC handler and the api v1 trace endpoints parse with model.TraceIDFromString, which acc

The separate-query e2e suite uses capabilities.E2EWithoutNativeFilters(), which skips the entire shared FindTracesWithFilter battery. This no longer describes the deployed storage path: Query API v3 → gRPC storage client/server → v2 memory store. Memory advertises native structured-filter support, and the storage gRPC API forwards both filters and filter capabilities. Relevant code: Separate-query suite Integration capability opt-outs Shared filter assertions Memory search capabilities gRPC storage reader Reproduction Replace capabilities.E2EWithoutNativeFilters() in TestJaegerQueryService with the zero-value capabilities, preserving any unrelated opt-outs, then run: go build -o ./cmd/jaeger/jaeger-e2e ./cmd/jaeger/internal/integration/jaeger-e2e STORAGE=query go test -race ./cmd/jaeger/internal/integration -run '^TestJaegerQueryService$' -count=1 -v A temporary Go test overlay making only that change produced 21 passing positive FindTracesWithFilter cases. Three refusal assertio

Requirement The internal query types carry search bounds as signed int while the values they stand for can never be negative, and the wire types they are translated to and from are not signed the same way. Every translation is therefore a conversion that a reviewer, gosec and CodeQL each have to reason about separately, and the query service has to refuse negative values that the type could have ruled out. Today: Field Internal type Wire type (jaeger.storage.v2) tracestore.TraceQueryParams.SearchDepth int int32 tracestore.Pagination.PageSize int uint32 The PageSize conversion in the remote-storage client (internal/storage/v2/grpc/tracereader.go) already carries a //nolint:gosec // G115, and CodeQL's go/incorrect-integer-conversion flags the same line once an HTTP parser feeds it a strconv-parsed value (seen on #9613). normalizeEnvelope refuses SearchDepth < 0 at runtime for a value that should not be representable. Proposal Make every depth and size field on the internal st

Requirement A client of the trace search API must be able to retrieve every matching trace, not only the first page. Today FindTraces and FindTraceSummaries return one page capped by search_depth, and everything past the cap is unreachable. The UI cannot offer "load more", and a program walking a time window cannot know whether it saw the whole result. Design RFC 0014 settles how this is done: an opaque page_token the caller echoes back for the next page, a next_page_token on the response, and a paginated capability that a backend declares so that one which cannot paginate serves a single capped page and says so, rather than returning a wrong one. Offset paging (limit/offset as in the v1 API) was weighed there and rejected (§3, §10), so a PR adding an offset parameter will be closed. Status Delivered: M1 protos, in jaegertracing/jaeger-idl#213. M2 storage contract, query-service admission and the PageChunk response envelope, in #9570, #9450 and #9585. Open, in order: The paginated