do we know what this comment refers to? "to do this" - do what?

"To do this" refers to replacing the float64 values that json.Unmarshal produces with uint64, because the actual query output uses uint64 (e.g., microseconds for durations). This ensures the test compares values with matching types.

json.Unmarshal parses all numeric values as float64 by default when decoding into interface{}.

We convert to uint64 because the function under test internally uses model.TimeAsEpochMicroseconds, which returns a uint64:
Source — TimeAsEpochMicroseconds

so we unmarshal a string that contains two "expected" numbers but then override those numbers with other values. Why not just construct the expected map directly? What's the value of unmarshalling the string?

The original test used JSON unmarshalling to handle nested fields like include_lower/include_upper. In the new query, that's no longer needed, but I kept the style consistent with the existing tests. Happy to simplify it if preferred.

Q: why store these values as fields instead of adding them directly to the map right away? It would reduce the amount of code

This RangeQueryimplementation follows the elastic.Query interface format:

type Query interface {
    // Source returns the JSON-serializable query request.
    Source() (interface{}, error)
}

This design is intentional and critical for compatibility with the existing Jaeger codebase. Many parts of Jaeger — such as query builders and Elasticsearch readers — expect all queries to satisfy the elastic.Query interface.

If we were to remove the Source() method or replace this with a direct map[string]any-style implementation, it would break the entire pipeline wherever elastic.Query is used. Calls like query.Source() would fail at compile time.

Moreover, this struct-based implementation is modeled after the previously used olivere/elastic/v7 library. By keeping the method signatures (.Gte(), .Lte(), etc.) and Source() behavior consistent, we ensure minimal refactoring and preserve the existing query composition logic.

So while a direct map-based query might look simpler in isolation, it’s not viable in this context. Our approach ensures:

• Full compatibility with the elastic.Query interface
• Minimal changes to existing logic

I am not suggesting changing the interface, but changing implementation where

func (q *RangeQuery) Lte(val any) *RangeQuery {
	q.lte = val
	return q
}

becomes

func (q *RangeQuery) Lte(val any) *RangeQuery {
	q.params["lte"] = val
	return q
}

Thanks for the clarification! You're right—refactoring to directly update params in the setters would simplify Source() and reduce redundancy. I’ll go ahead and refactor it that way.