Exception backtrace could be empty

[etehtsea]

I faced an issue when exception that had happen in my app don't show in Bugsnag UI.
I found that bugsnag backend silently swallow notification if there is empty stacktrace in any of exceptions.

:exceptions => [
  {:errorClass=>"Oxblood::Connection::TimeoutError", :message=>"Oxblood::Connection::TimeoutError", :stacktrace => <STACKTRACE>},
  {:errorClass=>"IO::EAGAINWaitReadable", :message=>"Resource temporarily unavailable - errno backtraces disabled; run with -Xerrno.backtrace=true to enable", :stacktrace=>[]}
]

Possibly it should be fixed in backend itself, but I can't do this. This is workaround for such issue.

P.S. Why don't you use 202 Accepted instead of 200 OK? It will cause much less confusion for such users (like me) who haven't looked in API documentation yet.
P.P.S. Possibly returning something like task_id that could be later used for checking processing status (using /status/:task_id) could be helpful for debugging such situations. This won't cause huge overhead if it will be made with, for example, 1 hour auto-expiration.

[renius]

(exception.backtrace.presence || caller).map do |trace| ?

[t3hk0d3]

@renius
#presence requires ActiveSupport, which is not in dependencies.

[kattrali]

Thank you for the contribution, @etehtsea. Its true, exceptions without stacktraces aren’t handled by Bugsnag, as without a stacktrace, errors are generally not actionable since there’s no indication where they originated or what to do with them. However, the library behavior to not fall through to caller looks like a regression.

P.S. Why don't you use 202 Accepted instead of 200 OK? It will cause much less confusion for such users (like me) who haven't looked in API documentation yet.

This is something to be fixed in a future version :) Depending on future implementations, 202 or 204 may be appropriate.

P.P.S. Possibly returning something like task_id that could be later used for checking processing status (using /status/:task_id) could be helpful for debugging such situations. This won't cause huge overhead if it will be made with, for example, 1 hour auto-expiration.

Interesting idea! I’ll forward that along to the backend teams.

[t3hk0d3]

@kattrali Is there anything preventing this PR from merging?

[martin308]

This looks good to me, I'll get this merged now and aim to sort out a release in the next day