Replies: 1 comment
-
|
Hi @xolf, While I get that this behaviour is a bit weird it actually allows us to keep track if a span did start a trace or not, that's the reason why we return null. Also it makes creating spans more lightweight since they will only be created when actually needed (although that behaviour is more usefull in the recorders). Have you seen the span method which takes a closure? This might solve the issue since it only requires one call the tracer. Albeit that sometimes adding extra closures to your code isn't possible. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've introduced spans into my Laravel project. To test the integration I've set the sample rate to 1. I've also added some custom spans into the code for long running/repeating tasks, like
For production use I have now reduced the sample rate and start received some
No span to endexceptions. After some quick digging I've found thatstartSpan()does returnnullif the trace is not recorded due to sampling.A more clean code/less noisy behaviour for seems to be that
startSpan()returns a span andendSpan()decided due to sampling whether or not it's going to be recorded or are there any ideas/preferences behind the current implementation?Beta Was this translation helpful? Give feedback.
All reactions