Closed rim99 closed 1 day ago
Thanks, I see why this test is failing and know how to fix it. However, it raises an interesting question about which data type we should use for the timestamps in the API. In api_v2 we used google.protobuf.Timestamp
, so api_v3 was trying to replicate that. However, in api_v2 the Span object also uses google.protobuf.Timestamp
, whereas in v3 we are using OpenTelemetry Span type which represents timestamps as fixed int64
fixed64 start_time_unix_nano = 7;
So while our api_v2 was consistent between data model and the service interface, api_v3 is not consistent.
I see, but unix nano level of timestamp seems to be too granular for API queries.
Current HTTP API uses micro seconds level of timestamp for "loopback". I think we'd better have a very good reason to break it
I agree, I don't really want to change api_v3 as it has been declared stable a long time ago. So we will continue using google.protobuf.Timestamp
, we just need to fix some annotations in the IDL and make a change in the Go repository. Specifically, the IDL file was missing these annotations:
// Enable gogoprotobuf extensions (https://github.com/gogo/protobuf/blob/master/extensions.md).
// Enable custom Marshal method.
option (gogoproto.marshaler_all) = true;
// Enable custom Unmarshal method.
option (gogoproto.unmarshaler_all) = true;
// Enable custom Size method (Required by Marshal and Unmarshal).
option (gogoproto.sizer_all) = true;
And then in the Go code I had to add a MarshalToSizedBuffer function to the Traces struct.
Do you want to try to make these changes?
Test would fail on proto marshal