4

I have searched and found this, but it is not the same question.

I would like to suppress log statement for some classes. In older versions of Salesforce we were able to do this via the Trace Flags tab on the apex class page.

Now in version 40 (started a few releases ago) the Trace Flags tab is different and you can only turn on logging.

I created a log level that has each category set to None and assigned it to a class and what I get instead of nothing is this noise repeated for every debug statement that would have been there:

11:29:19.0 (16907488)|PUSH_TRACE_FLAGS|[EXTERNAL]|01p60000000UmVB|my class name|APEX_CODE,NONE;APEX_PROFILING,NONE;CALLOUT,NONE;DB,NONE;SYSTEM,NONE;VALIDATION,NONE;VISUALFORCE,NONE;WAVE,NONE;WORKFLOW,NONE 11:29:19.0 (17017401)|POP_TRACE_FLAGS|[EXTERNAL]|01p60000000UmVB|my class name|APEX_CODE,DEBUG;APEX_PROFILING,DEBUG;CALLOUT,DEBUG;DB,DEBUG;SYSTEM,DEBUG;VALIDATION,DEBUG;VISUALFORCE,DEBUG;WAVE,INFO;WORKFLOW,DEBUG

Improve this question

1 Answer 1

Reset to default
3

Unfortunately that is the primary logging telling you about the transition into the class specific logging levels and back via the PUSH_TRACE_FLAGS and POP_TRACE_FLAGS events.

Say you call from the transaction into class B that has a specific TraceFlag with LogType 'CLASS_TRACING'. If the System level logging on the transaction is set to INFO or lower you will get the PUSH_TRACE_FLAGS on the way in and then POP_TRACE_FLAGS when the method completes. The problem you are seeing is if class B then makes calls out to other classes (both constructors and methods). These calls will all also get their own PUSH/POP pair. If class B has a lot of dependencies on other classes your log could be rapidly growing again.

I suspect it has some roots in the known issue - Spring 16 Class-level trace flags overriding general trace flags when more restrictive. If every transition between classes isn't considered it isn't possible to determine the correct logging levels that should be applied.

The simplest fix would be to set the System level debugging to NONE for the transaction.

Another alternative is to use a third party Apex log parser that can explicitly ignore certain log events. It won't directly help with Apex log size issues, but will make the log more readable.

Shameless plug for the FuseIT SFDC Explorer here (Disclaimer: distributed free via my current employer).

enter image description here

Improve this answer
2
  • Thank you. What I am trying to prevent is the entire log file. It is the noise in the developer console list. That is my issue; the filtering in the log list is very limited in what it filters on. Also the debug log in Salesforce no longer has paging. I find it difficult to open or download the log file I want.
    – Maggie
    Jul 20, 2017 at 13:32
  • Also thank you for the parser info I will look at it.
    – Maggie
    Jul 20, 2017 at 13:37

You must log in to answer this question.

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