Support for context in nested exceptions (causes)

[subzero10]

Context

We recently had an issue reported in which a user tried to use the cause property with a non-error type object. This should be expected behavior in javascript.

In order to support a dynamic data structure, a slack discussion brought us to the following proposal:

• Add a new context (name to decided) property in the causes.items.properties schema.
• The properties class, message, backtrace will have to become optional.
• In the case of the javascript issue above, we would put the JSON result of the non-error type cause object as the data for the context property. The other properties (class, message, backtrace) will not have any value.
• For Ruby, we already have support for a context on the main error/exception. This context is merged with the global context. For each error/exception in the nested causes, we could add their context in this new property.

Obviously, this implies that work will have to be done on the backend (?) and Honeybadger UI to support this new property and the dynamic data structure of a cause object. For example, the following block only works when the cause item has the properties class, message, backtrace. We will have to modify to support cases where these properties are not set or when the context property has a value, which will be a dynamic JSON structure.

Let me know what you think!
cc @joshuap

[stympy]

I like this approach, but I'm a little concerned about overloading the term context, since so far that term has been used only for additional metadata related to the original error. Could we use something like details instead?

[subzero10]

If you look at the Slack discussion, we have cycled through cause_custom, raw, data and context for the name of this property 😄 .
I really can't decide on a name, but we have to bear in mind that for nested Exceptions in Ruby which define a to_honeybadger_context method, their result would be added to this new property. So one could justify the use of the same name for global context and nested context, just as we have a main/parent exception and nested exceptions 🤔 .

In any case, I have no strong opinion; we can go for details 👌 , or take a vote.

[stympy]

Heh, fair enough... Having to_honeybadger_context does tend towards having a nested context in addition to the global context. Consider my concern resolved. 😁

[joshuap]

Heh, fair enough... Having to_honeybadger_context does tend towards having a nested context in addition to the global context. Consider my concern resolved. 😁

We also don't necessarily have to call it context in the UI. Or, we might call it different things in the UI depending on the language (i.e. in JS it has a specific meaning, but in Ruby it's something else). I don't know if we're getting ourselves into trouble with the dual-use case thing, but it does seem to technically solve both use cases. 😅

[joshuap]

Nice writeup @subzero10!

I think @shalvah's input on this would also be valuable.

[shalvah]

With regards to the original idea, I'm a bit wary of adding a context field on a cause item. Since the cause items were originally made to model the top-level error type, it feels odd to give them a field error doesn't have, just for the JS use case. 🤔 Especially since we expect only two usage patterns:

• class, message, and backtrace are present, but no context
• context is present, but no class, message, orbacktrace.

I'm thinking of making cause a freeform object instead. It can be an error (class, message, and backtrace), or a regular hash. If it's a hash, we can then just give it a simple key => value display in the Causes section. What do you think?

But from the conversation, it looks like we're extending this to the idea of also recording the result of exception.to_honeybadger_context for causes, then I'm good. 👍

[subzero10]

I'm thinking of making cause a freeform object instead. It can be an error (class, message, and backtrace), or a regular hash. If it's a hash, we can then just give it a simple key => value display in the Causes section. What do you think?

Yes, I believe that's how we originally started with this.

And then @joshuap asked if it made sense to introduce a change that would also cover the exception.to_honeybadger_context inside causes.

Personally, I think it's fine:

• we are adding the context field for the exception.to_honeybadger_context use case
• and to cover the js exceptional case, we are allowing causes to have a context field only