[Bug]: Storage v2 gRPC search handlers panic when query is omitted

[ADITYA-CODE-SOURCE]

What happened?

As an operator or implementer using the storage v2 gRPC API, I want malformed search requests to return a validation error so that they cannot trigger a server-side panic.

The storage v2 FindTraces, FindTraceIDs, and FindTraceSummaries handlers panic when the request omits the nested query message.

Each handler passes req.Query directly to toTraceQueryParams(). Protobuf permits this message to be omitted, in which case req.Query is nil. toTraceQueryParams() dereferences the pointer without checking it, causing a nil-pointer panic before the storage reader is called.

This affects all three storage v2 search RPCs and is independent of the configured storage backend.

Steps to reproduce

1. Run a storage v2 TraceReader gRPC server using the current main branch.
2. Independently call any of the following RPCs with an empty request, leaving the nested query message unset:

client.FindTraces(ctx, &storage.FindTracesRequest{})
client.FindTraceIDs(ctx, &storage.FindTraceIDsRequest{})
client.FindTraceSummaries(ctx, &storage.FindTraceSummariesRequest{})

3. Observe that the selected handler calls toTraceQueryParams(nil).
4. Observe a nil-pointer panic when toTraceQueryParams() accesses a field such as t.ServiceName.

The panic occurs before the configured storage reader is invoked.

Expected behavior

Requests that omit the required query message should be rejected with gRPC status code codes.InvalidArgument, for example with the message missing query.

The handlers should not panic, and the storage reader should not be called.

This would match the existing API v3 gRPC query handler, which already returns codes.InvalidArgument when its query message is missing.

Relevant log output

panic: runtime error: invalid memory address or nil pointer dereference

github.com/jaegertracing/jaeger/internal/storage/v2/grpc.toTraceQueryParams(...)
github.com/jaegertracing/jaeger/internal/storage/v2/grpc.(*Handler).FindTraces(...)

The equivalent panic can originate from FindTraceIDs or FindTraceSummaries.

Screenshot

Not applicable.

Additional context

The affected handlers pass the nested query directly into the conversion helper:

• FindTraces
• FindTraceSummaries
• FindTraceIDs

toTraceQueryParams() dereferences the pointer without validating it.

The storage v2 protobuf definitions define query as a nested message, which can be omitted from a protobuf request.

The API v3 gRPC conversion helper already handles the equivalent condition by returning codes.InvalidArgument with missing query.

A focused fix could validate the pointer during query conversion, propagate the validation error through all three handlers, and add regression tests confirming that each RPC returns codes.InvalidArgument without invoking storage.

I searched existing issues and pull requests for storage v2 query panics, omitted queries, missing queries, nil queries, FindTraces, FindTraceIDs, and FindTraceSummaries. I did not find an existing report for this behavior. Issue #9099 concerns an omitted search_depth field inside a present API v3 query, so it is a different problem. Issue #8002 was an unrelated clock-skew adjustment panic and has already been resolved.

AI assistance was used to inspect the affected code paths, search for duplicates, and prepare this report. I reviewed the findings against the current source.

Jaeger backend version

main (7de15980f51060103ee5a90fbe2096c87a70a523)

SDK

Not applicable. This affects direct clients of the Jaeger storage v2 gRPC API.

Pipeline

Storage v2 gRPC client -> jaeger.storage.v2.TraceReader server -> storage v2 reader

The panic occurs in the gRPC handler before the storage reader is invoked.

Stogage backend

Any storage backend. The panic occurs before backend-specific code is called.

Operating system

Not operating-system-specific.

Deployment model

Any deployment exposing or using the storage v2 gRPC TraceReader service.

Deployment configs

Not applicable.

[alehhu]

Hi there! 👋

I'm still getting familiar with this part of the codebase, but it seems like a straightforward nil pointer issue. I think the cleanest way to fix this would be to add a simple if req.Query == nil check at the top of all three handlers (FindTraces, FindTraceIDs, and FindTraceSummaries). By doing this, we can immediately return a codes.InvalidArgument status with a "missing query" message, completely preventing the panic before the storage reader is even touched.

I've already started playing around with this locally and writing some regression tests for the RPCs

Would you be open to me submitting a PR for this? Let me know if you think this is the right direction or if I'm missing any edge cases!