Debug Log issues in Winter/Summer ’16

Lately we have been noticing issues with the Debug Logs.

Missing debug lines

Sometimes either CODE_UNIT_STARTED or CODE_UNIT_FINISHED goes missing. For example The log shows when a trigger finished running but omits its starting point. There are no skipped lines (due to large log size) in between the 2 expected events. We are also seeing debug statements that don’t match their sequence in the code. For example if “debug 1” and “debug 2” are written back to back, sometimes we only see “debug 2”.

Missing debug logs

Sometimes there are no logs even though the proper window is set for the user.

Nonoperational trace flag overrides

Sometimes overridden trace flags for classes don’t work. The Winter ’16 release seems to be at fault as explained in this SE post and also in this article.


I know this is a duplicate of my earlier post referenced above but for completeness I’m including it here again. Basically my logs in a namespaced DE org are now filled with ENTERING_MANAGED_PKG statements.

Does anyone have any hacks to offer? Some have suggested that Apex Profiling may be responsible for at least some of the issues but I have it set to None.

I have been developing on SFDC for 7 years now, and I am slowly starting to lose confidence in it. Debugging is the very basic of any development platform and without it you simply can’t take it seriously.


So, after 49 days of back and forth with Salesforce Support on Case 15448344 the conclusion they came to with missing CODE_UNIT_FINISHED entries is…

As the logic is entering the managed package, the complete log lines are getting hidden and this has been proved previously as soon as we expose the logs for the managed package, the entire logs gets visible.

This is WAD [Works As Designed] . You will see equivalent CODE_UNIT_FINISHED and CODE_UNIT_STARTED if the logic or the context is not entering any managed package.

If you have any managed package components active in the Apex Debug log then you are going to get unmatched logging events unless you have access to the managed package namespace. You can either use the LMA to get access to your namespace or request support to expose the namespace (if you can get permission granted from the managed package provider).

I’d personally go with BAD [Broken as designed]. I’ve raised the idea Expose matching pairs of log events when managed packages are present

You might also like to vote for Debug logging level that will prevent ENTERING_MANAGED_PKG appearing in the log.

Source : Link , Question Author : Mossi , Answer Author : Community

Leave a Comment