I use the x/net/trace package to trace requests, and I am running into a 
panic caused by adding to a trace after it was Finished[1]. 

Here's the scenario:
- One incoming request leads to 2 parallel requests to backends. 
- We return the fastest backend's response to the user and Finish the trace.
- Anything subsequently added to a trace by the slower backend results in a 
panic, if that trace has already been recycled (a race condition).

Here are the options I can think of:
- Wrap the trace.Trace with an implementation that tracks whether Finish() 
has been called and ignores subsequent calls. 
- Check the context before adding information to a trace, under the 
assumption that the context will be canceled if the trace is Finished.

Any others I'm missing?

Do you think it's worth opening an issue to have the library gracefully 
ignore events on finished traces? 
The rationale is that it seems efficient to implement, and this issue seems 
like it would come up in any server that uses concurrent goroutines to 
process a request. Although I noticed it because the happy path of my 
server is unusual, I think this could arise in any server that uses 
concurrent goroutines, if one of them returns early with an error while 
others are still processing. Having a panic taking down your server due to 
an unrelated error condition seems like something to avoid. 

Thanks for your thoughts,

[1] To the authors: thank you for leaving this helpful note! 

func (tr *trace) addEvent(x interface{}, recyclable, sensitive bool) {

                NOTE TO DEBUGGERS

                If you are here because your program panicked in this code,
                it is almost definitely the fault of code using this 
                and very unlikely to be the fault of this code.

                The most likely scenario is that some code elsewhere is 
                a trace.Trace after its Finish method is called.
                You can temporarily set the DebugUseAfterFinish var
                to help discover where that is; do not leave that var set,
                since it makes this package much less efficient.

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to