Stack trace not displayed when calling Rollbar.error("message")

[santi-h]

Doing

Rollbar.error("TLE PDF Attachment => [ERR] Failed to create claim: #{claim.errors.messages}")

produces an item like this:

Seeing an item like this without a stacktrace gives us many difficulties:

• I have to search throughout our entire code base for strings like "TLE PDF Attachment => [ERR] Failed to create claim" to see exactly where this is getting raised. This makes it difficult to find it sometimes because we might have similar messages in different places.

• Some words might be dynamically added. For example, in this case, "{:provider=>["can't be blank"]}" is computed at error time, so we can't search for that in our code.

• Sometimes it's not easy to recognize what parts of the message were computed dynamically and what parts weren't.

• If "PDF" was dynamically added, then finding the string would've been a pain, because we'd search for "TLE PDF Attachment" and of course we wouldn't get any results.

To get around this problem we had to create this gem, but I was wondering if there's any support for this already that we're not aware of?

Thanks in advance!

[jondeandres]

Hi @santi-h, thanks for opening this issue.

We have a configuration option config.populate_empty_backtraces that popualtes the backtrace for not rescued exception, ex: Rollbar.error(Exception.new(message)). I know this is not the same, but is something. The code for this is https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar/item/backtrace.rb#L92-L99.

The logic you have in your gem could reside in https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar/item.rb#L187-L193. We'll think on this and reach you on this issue when we have a conclusion about what to do.

Thanks!

[rokob]

I think the solution here is that we should have an option to include backtraces with messages which is off by default. The implementation being what is in this gem. It is a common enough request.

[jondeandres]

@rokob do you think it has sense to use the same option we have now and just populate backtraces also reporting messages without exception?

[ArturMoczulski]

@jondeandres if I understand correctly, you're suggesting to add logic behind populate_empty_backtraces to also populate backtraces for messages. So it's the same thing @rokob suggested just put in the already existing populate_empty_backtraces option? Is that correct?

[rokob]

Yeah that's what I understood and I agree, we might as well just have one option.

[jondeandres]

@ArturMoczulski that's correct, yes, let's use the same option, imho

[rivkahstandig3636]

Hi there, I’m closing out all issues opened before 2018 that haven’t had any activity on them since the start of this year. If this is still an issue for you, please comment here and we can reopen this. Thanks!

[santi-h]

Hi @rivkahstandig3636, is there any way to display the stacktrace of a Rollbar.error(msg) call that we're not aware of? If not then this is still an issue for us

[adaslesniak]

I am using Rollbar and have the same problem. I can: A - send logs when app crashes manually and attach custom data which is super helpful B - trust that you will report crash correctly and provide stacktrace but there is no additional data it's iOS client so symbolication is an issue, I can't just dump stack trace into txt myself.

So question is: 1 - can I ask for stacktrace to be added to message (and translated to human readable thing) 2 - can I inject some additional data to your crash report

[gingerlime]

Also bumped into this. For now, I'm using something similar to this as a workaround

err = RuntimeError.new(msg)
err.set_backtrace(caller)
Rollbar.error(err, :log_extra => some_extra_data)

(the extra stuff isn't immediately visible on Rollbar, but you can see it if you click on the occurrence)

[gerrywastaken]

@ArturMoczulski @rokob @jondeandres this seemed like a great idea. Any idea why there hasn't been more movement on this? Messages can end up being almost useless without this info and it would be great to just always have a stack trace. This is actually what I thought this option would have done by default.

[rokob]

The thing stopping the easiest implementation is that the API spec does not allow both a trace and a message as part of the body of the item payload. So If you wanted the item to be a message, i.e. have data.body.message with information, then you can't also have data.body.trace which is where we would put the stacktrace. So we have two options that I see:

1. Convert a message to a trace if populate_empty_backtraces is true, this would be equivalent to transforming Rollbar.error(your_message) to Rollbar.error(Exception.new(your_message))
2. If you have a message and populate_empty_backtraces is true, then put a stacktrace somewhere else in the payload, probably in extra or custom.

(1) Seems to be the closest to what people here are looking for as you would see the stacktrace in the UI properly, the message would still end up getting indexed as the title. But it would mean you no longer have the slim message type payloads.

(2) This would be more idiomatic to the API spec as a message is not an exception and the stacktrace for where the message originated is extra data associated to the message. The downside is that the stacktrace would not get surfaced the same was as exceptions in the UI so the usability of this option is not great.

Building a stacktrace is not free both computationally as well as in payload size. So including a stacktrace with all messages is not done to allow messages to have this lighter weight. I think we can do what I describe in (1) above via the configuration option which is false by default.

[printercu]

What do you think about (1) with option to disable/enable backtrace?

# when populate_empty_backtraces = true
Rollbar.error('msg', backtrace: false)
# when populate_empty_backtraces = false
Rollbar.error('msg', backtrace: true)

Also Rollbar.error(Exception.new('test')) appears in Rollbar as Exception: test. It would be great if message appeared without extra prefixes.

[ciriousjoker]

Is this ever going to be fixed?

[waltjones]

The blocking issue on this is that the Rollbar API doesn't yet support it. If a trace is sent with a message payload it will either be ignored or rejected as invalid.

[slohmeier-onemedical]

+1 for this feature! For now we're getting around it by just passing a backtrace as an extra parameter in the rollbar call:

msg = "Uh oh something bad happened"
Rollbar.error(msg: msg, backtrace: caller)

But it would be awesome if we could take advantage of the nice backtrace cleanup and display that rollbar provides for exceptions!

[swistak]

Also very interested in this. Exception message seems to be passed around without any problem in Rollbar. So wouldn't the easiest workaround be just to create Rollbar::Message exception, then just don't display that sepcific exception in Rollbar UI?

[waltjones]

@swistak That is close to the best thing I know to recommend: Sending an exception report with level set to info (or really any level you want.) This has a message and a stack trace, and won't be treated as an error. For now, anyone could do this themselves by passing an exception object to Rollbar.info(). Using meaningful exception classes should be considered though, as they can be used by the grouping algorithm to improve grouping results. Likewise, ignoring the class on the dashboard side is probably possible, but is more than just not displaying it. It gets consumed in others ways as well.

Aside from any feedback about the SDK interface for this, would the above solution with the exception class displayed be acceptable for people on the dashboard side of the project?

[bellef]

What do you think about (1) with option to disable/enable backtrace?

# when populate_empty_backtraces = true
Rollbar.error('msg', backtrace: false)
# when populate_empty_backtraces = false
Rollbar.error('msg', backtrace: true)

I would love to have an API like that @printercu

[spacecowgoesmoo]

This adds a stack trace in our env.

function sendErrorToRollbarManually(message) {
	const err = new Error(message);
	// window.Rollbar.error(message); 	// sends the message string only
	window.Rollbar.error(err); 		// sends the message string with a stack trace
}