Best Practice to pinpoint bugs in your managed code that only occur in customer orgs

Question

When code in a managed package fails in a customer org it does not produce logs. This is a serious problem for the ISV that needs to provide a fix but is unable to reproduce the bug in his development org.

I expected the "Notify on Apex Error" field on a package to work much better, as I do not receive error emails in all cases and they often miss a helpful stacktrace.

I've heard of custom logging solutions that write custom object records on the customer org, that persist logs and notify the ISV. The problem I see with this solution is that the logging DML might generate limit problems or log records might often not be inserted due to Database rollbacks.

How do you cope with such situations?

Answer 1

Subscriber Logging and Full Debug. In the ISVForce Guide, there is a section on supporting your customers, Troubleshooting in Subscriber org.. Note you will need to pass the Security Review to enable Subscriber Support login for you package (as well as a number of other features such as Push Upgrade).

"When logged in as a user in a subscriber’s organization, you can generate Apex debug logs that contain the output from your managed packages. This includes logging that would normally not be exposed to the subscriber. Using this log information, you can troubleshoot issues that are specific to that subscriber organization. "

Custom Object Logging. However some times you do want to capture more functional log entries for review by your users or yourself. In this case managing database transactions is important. Here is an answer I gave before on the topic, Can I prevent an insert to be rolled back even if my class (later) runs into an exception?. Note that a Unit of Work (UOW) pattern is also a good way to create a unique UOW to capture log records outside of your main unit of work and then commit the log entries as shown in the answer in the finally.