If a custom object responds to id method, show the id and class value, instead of showing "[OBJECT]" in error reports

[manojmj92]

Goal

When bugsnag prints out the arguments passed to a job, if the arguments are custom objects (like a Struct, or an ActiveRecord object), Bugsnag only prints out "[OBJECT]" in its place, instead of providing any details, like

{
  "class": "SubcriptionRenewalJob",
  "args": {
    "user": "[OBJECT]",
    "account": "[OBJECT]",
    "setting": "[OBJECT]",
    "subscription": "[OBJECT]"
  }
}

While bugsnag does this for the right reason (we should not show details of the whole object using inspect, because of PII), for developers who have not written a to_s in the model, just seeing "[OBJECT]" in place of the actual object details becomes a nightmare. Such errors become practically impossible to debug because, well, you do not know which object caused the issue.

This PR is aimed at solving this problem to some extent, ie, at least in case of ActiveRecord objects.

Design

All ActiveRecord objects have an id method on it by default. If the custom object does not respond to to_s and we cannot show it on bugsnag due to data-sensitivity issue, we can still show the id of the object.

Reasons:

1. ID is technically not a sensitive data point, like say email or address (which could be exposed if we give out the whole value of inspect on an object)
2. For developers debugging the issue, just knowing the ID of the object should suffice to go back and fetch the record from the database, for debugging purposes.

Result

Bugsnag will now show arguments as

{
  "class": "SubcriptionRenewalJob",
  "args": {
    "user": "[OBJECT]: [Class]: User [ID]: 23",
    "account": "[OBJECT]: [Class]: Account [ID]: 18",
    "setting": "[OBJECT]: [Class]: Setting [ID]: 7",
    "subscription": "[OBJECT]: [Class]: Subscription [ID]: 88",
  }
}

Changeset

Added

Added condition to check if the object responds to id method. If so, the id of the object is being returned as the value of the argument.

Removed

Changed

Tests

Added tests to assert that for custom objects that respond to the id method, the id of the object is returned as the value of the object, rather than the string "[OBJECT]"

Discussion

Alternative Approaches

Outstanding Questions

Linked issues

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language

[imjoehaines]

Thanks for the PR @manojmj92 — I've fixed the conflict and will merge this in #605 🙂