Better error stacktraces for Cloud Errors #42
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.
Anyone is free to use our fork as long as this is not merged. Use this in your go.mod:
Stackdriver / GCP Cloud Errors is quite picky about the stacktraces it will parse. Specifically it does only parse the output of Go's
runtime.Stack()
which notably includes agoroutine \d [running]:
part. Without those stack contents it does not parse.This PR adapts zapdriver to include better stacktraces by default, when the error is reported to Cloud Errors (e.g. when the context and service name are set). It also uses the
exception
key instead ofstacktrace
because Cloud Error only contemplates themessage
,stack_trace
andexception
fields of thejsonPayload
. Thestacktrace
key wasn't inspected at all, and even if it were, it contains the Zap formatted stack, which isn't compatible with Cloud Errors.To view how this works, consider for example these different configurations:
The output would be as follows:
In Cloud Errors this would show as:
Any other format (like Zap's stack format) would wrongly display as such:
The inspiration from this format comes from this error report:
googleapis/google-cloud-go#1084 (comment)