Concatenation of trace context for asynchronous requests in different goroutine

[CoderPoet]

Feature request

This repo is the best idea I've seen recently !!!

Will consider supporting the scenario of starting a new goroutine for asynchronous client requests ? In this scenario, is it impossible to connect the trace context through the goroutine context map ?

[edeNFed]

Hi @CoderPoet happy to hear that you like this project! 😄 We are currently working on refactoring the goroutine tracking mechanism. The new implementation will keep track of the goroutine creation tree instead of a single goroutine, which will solve this issue.

It should be finished in the next couple of weeks, stay tuned :)

[edeNFed]

Hi @CoderPoet. Please try version v0.6.0. We changed the way we do context propagation and it no longer depends on goroutine ids, so passing context between different goroutines should work.

[CoderPoet]

Hi @CoderPoet. Please try version v0.6.0. We changed the way we do context propagation and it no longer depends on goroutine ids, so passing context between different goroutines should work.

Whether the bpf_probe_write_user function is safe and whether it will have other side effects?

[CoderPoet]

Hi @CoderPoet. Please try version v0.6.0. We changed the way we do context propagation and it no longer depends on goroutine ids, so passing context between different goroutines should work.

Whether the bpf_probe_write_user function is safe and whether it will have other side effects?

eg. In the go1.20 version, will there be problems with the memory GC of the header slice with Arenas?

[edeNFed]

Hi @CoderPoet We allocate memory in an area that is not affected by the GC. Recent changes like the addition of arenas should not have an effect on this.

[CoderPoet]

@edeNFed Another problem is how to communicate the context in the process, adding it without integrating any otel SDK. For example, function A calls function B