Conversation
| def gen: F[SpanId] = _gen | ||
| } | ||
|
|
||
| implicit def threadLocalRandomSpanId[F[_]: Sync]: Gen[F] = Gen.from(Sync[F].delay { |
There was a problem hiding this comment.
I assume that cats.effect.std.Random is not an option here (though it expresses the capability of generating some random bytes way better than Sync because it's not in cats-effect-kernel?
Other than that, the PR looks good to me 👍
There was a problem hiding this comment.
I intentionally didn't use Random as a bound on F[_] since it doesn't have auto derivation from Sync.
I could summon Random instance within my implementation, but that's not even shorter and brings cats.effect.std dependency.
|
P.S. We force new integrations to be compatible with the rest t4c ecosystem. AWS X-Ray is ok since it uses the same 16-byte traceIds, but not fully random, but partially clock-based. These traceIds will work fine with all the tracing systems we have integration with. |
janstenpickle
left a comment
There was a problem hiding this comment.
Looks good to me, thanks 👍
|
@mrdziuban please, confirm you're fine with this PR, then I'll merge it and you can proceed with yours |
|
👍 yup, looks good to me! |
General info
During @mrdziuban's work on trace4cats/trace4cats-xray#4 we've realized that we don't have a mechanism for overriding the way of generation of TraceId/SpanId. This PR introduces typeclasses for providing generators for them.
We now require
F[_] : TraceId.Gen : SpanId.Genbounds in the whole model fromSpanContexttoSpantoEntryPoint. That is, we now can provide an X-Ray compatible traceId generator toEntryPoint.apply[F]if needed.I also replaced wide bounds (e.g.
Sync[F]) with fine-grained multiple bounds.This change is (almost) fully source compatible, i.e. all the newly introduced context bounds are automatically derivable via previously existed bounds (e.g.
Sync[F]). If a user didn't provide them explicitly, they shouldn't have any errors with recompilation. And, of course, the change is not binary compatible.The default instances (as previously) are based on
ThreadLocalRandomwhich is a fast, threadsafe, but cryptographically insecure RNG. Tracing seems to be a proper field of usage for such a generator.How I see the usage of alternative generators on example of AWS X-Ray
We put alternative generators in a separate package named
trace4cats.xray.compatin forms of implicit and explicit instances.Code sample
When a user constructs an
EntryPoint, they should provide the custom instance either via a global import clause or via a local instance.Code sample
or
There's also an option to provide a custom object with a factory
applymethod that uses custom generators, but as for me it doesn't seem more discoverable or clearer.