5

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.

ENTERING_MANAGED_PKG litter

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.

Improve this question
10
  • Somewhat related: salesforce.stackexchange.com/questions/122632/…
    – Adrian Larson ♦
    Jun 2, 2016 at 18:39
  • 1
    I'll just comment and hopefully someone else can offer some additional ideas. With regards to missing debug lines. If you can provide sample code to reproduce it I can help raise it with Salesforce support if you want. I'd also check the raw text debug logs incase the developer console is corrupting them.
    – Daniel Ballinger
    Jun 2, 2016 at 23:38
  • 1
    With the ENTERING_MANAGED_PKG entries bloating the log, be on the lookout for MAXIMUM_DEBUG_LOG_SIZE_REACHED and "*** Skipped 3799560 bytes of detailed log" messages. Especially the skipped one where it randomly chops out the middle of the log.
    – Daniel Ballinger
    Jun 2, 2016 at 23:40
  • 1
    @DanielBallinger Appreciate that! I can raise the case as well but I'm not keen on taking the time to create yet another turnkey sample code for the SF Support; seeing a support ticket through is like watching grass grow. I cannot post any sample code because almost all logic goes through installed managed packages (and I will have to obfuscate everything before I can post it!).
    – Mossi
    Jun 3, 2016 at 0:31
  • 1
    @DanielBallinger that's what Support kept telling me too -which didn't make sense because our log size was not even 100KB. So we just got in touch with our contact at SFDC. She confirmed the debug logger is buggy and suggested me do what I shared above. My Support case was never resolved and our confidence in the debugger continues to remain low.
    – Mossi
    Jan 9, 2017 at 21:56

1 Answer 1

Reset to default
2

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.

Improve this answer
5
  • So does that mean if a trigger calls managed code or cascades into a managed trigger we see the START but not the FINISH statement? This explanation makes no sense. Either show both or don't show them at all.. +1 on BAD. Btw I'd already upvoted your Log Level idea.
    – Mossi
    Feb 24, 2017 at 1:15
  • That was the message I consistently got from support. If it goes through a managed package you will see it start, but the finish will be missing without access to the namespace. They didn't seem to think there was anything wrong with that. So I'm left with the only other avenue, which is the idea exchange.
    – Daniel Ballinger
    Feb 24, 2017 at 1:21
  • @DanielBallinger - I am seeing this consistently in non package orgs. IC debugger cannot process because the matching entry points are not presented. I do not have the fortitude to submit a case after being told that an ISV cannot see debug logs when logged in via LMA and that the only way to see them was to raise a ticket and ask for them to be unhidden. We continue to just muddle through
    – Eric
    Feb 24, 2017 at 2:37
  • @Eric I've been able to pull the debug logs for my package when logged in via the LMA. I did find that I couldn't download the logs via the developer console. Instead I needed to copy and paste out the raw log view.
    – Daniel Ballinger
    Feb 24, 2017 at 7:54
  • 1
    Yes. We are seeing logs run in a batch from dev console being hidden. If execute called directly logs are visible. Been frustrating. We had to make some global so we could debug and run directly. Now we have all the issues with marking the methods global. Ugh
    – Eric
    Feb 24, 2017 at 7:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .