Asynchronous calls to raygun, having captured stack traces in the relevant thread #9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The point of this small-ish change, is to allow us to call raygun asynchronously. This avoids execution delays, while still retaining the relevant stack trace. We have been using this branch in production for a couple of months now.
CreatePost
andSubmitPost
are 2 new methods, to be called on separate goroutines.CreatePost
captures the stack trace into a typePost
(the stack trace is stored in a private variable,.postData
).CreatePost
is quick and can be called inline.SubmitPost
provides an entry point with which to send thePost.postData
.SubmitPost
is exposed to internet speed/reliability -SubmitPost
should be called from a separate goroutine.CreatePost
provides some more control over stack trace truncation. In the example below,4
represents the usual number of stack frames to truncate. If you wrap this call inside another function, you may want to vary this parameter - e.g. we typically wrap the call two functions deep, so we use the value6
.Here is how you might use it:
Note that I'd normally add in some
defer
...recover
handling, but I've left that out for sake of simplicity.Existing usage patterns should not be affected by this change. Cheers