Scope of the Span not working as expected with Ratpack Promises about brave-ratpack HOT 10 CLOSED

@llinder @adriancole @beckje01 Can you guys take a look at the modified sample app
https://github.com/kirenjolly/ratpack-kotlin-demo
And check whether i am doing wrong or missing something.
Or this is an issue with Ratpack Promises

from brave-ratpack.

taking a look

from brave-ratpack.

not exactly sure what this example app is trying to do. It took some time to figure out how to run it, which is kindof time lost.

curl -X POST http://localhost:5050 -H'Content-Type: application/json' -d '{}'

if possible, please instead add a test case to this as what you are mentioning doesn't seem to require a standalone app to vet https://github.com/openzipkin-contrib/brave-ratpack/blob/master/src/test/java/brave/http/ITServerTracingModule.java#L44

from brave-ratpack.

possibly related if coroutines are somehow at play here. openzipkin/brave#820 (comment)

from brave-ratpack.

@adriancole This is a simple ratpack-kotlin app which has a chain that has a all handler. so i am able to get the httpTracing.tracing().currentTraceContext() till the parsejson function.
As parseJson is expecting a promise and then evaluates the promise value.
So when promise is encountered the scope of the server span is somehow closed and hence removes all the TraceContextHolder value in registries.
Thus when i form a new span child it forms as a seperate trace.
This is the exact scenario where i was facing issues from the begining.
So help me out with this same case.

from brave-ratpack.

@adriancole So At what scenarios does the scope of a span closes unless we specify it explicitly.
Does the scope automatically closes on encountering a promise?

from brave-ratpack.

This app is just trying to prove that the scope of span fails on promises.
you can hit localhost:5050/main in postman to see that after running the application.
i couldn't figure out why does it took time for you to run it

from brave-ratpack.

from brave-ratpack.

Making a request:

curl -XPOST -H "Accept: application/json" -H "Content-Type: application/json" localhost:5050/main -d '{"trace_id":"1","trace_name":"name"}'

Output:

[ratpack-compute-1-9] INFO InitialHandler - InitialSpan: RealSpan(f8dcd4ea5ff36a8b/f8dcd4ea5ff36a8b)
[ratpack-compute-1-9] INFO InitialHandler - initialSpanInChain: RealSpan(f8dcd4ea5ff36a8b/f8dcd4ea5ff36a8b)
[ratpack-compute-1-9] INFO InitialHandler - idFromRequestBody: 1
[ratpack-compute-1-9] INFO InitialHandler - is Span Context present in tracer: false

Ultimately it looks like context is null when calling this line: https://github.com/openzipkin-contrib/brave-ratpack/blob/master/src/main/java/ratpack/zipkin/internal/RatpackCurrentTraceContext.java#L43

Also, a new trace context holder ends up in the execution registry in the .then block with an empty context, where the the trace context holder pre-then does contain a context. When debugging the above line I can see different objects. Not yet sure why this is.

from brave-ratpack.

I think this issue is also unique to parsing request bodies.

from brave-ratpack.