Does the Summer ’15 release remove the ability to set test logging levels with the DebuggingHeader?

Question

The Summer ’15 release notes have a section called Receive Debug Logs Predictably.

It currently states that the order of precedence for debug logs will be:

1. Trace flags set in the Developer Console override all other logging logic.
2. If you don’t have active trace flags, synchronous and asynchronous Apex tests execute with the default logging levels.
3. If no relevant trace flags are active, and no tests are running, your API header sets your logging levels.
4. If you enable system logs for a user, you get debug logs for that user’s next 20 requests.
5. If your entry point sets a log level, that log level is used.

The order of points 2 and 3 seem a bit off to me.

If I explicitly set a DebuggingHeader on an API request I'd expect it to take precedence over the default values for synchronous and asynchronous Apex tests.

In fact, I'd expect an explicit DebuggingHeader to take precedence over a TraceFlag as well.

How can I control the logging level for test cases at the API call level without defining a TraceFlag? If I had to define the TraceFlag it will affect all logging for the given user.

---

IMHO, the following order would make more sense. All are based around excluding a previous match and the applicable record/header etc... being defined.

1. The API DebuggingHeader header sets your logging levels for that transaction.
2. TraceFlag for the user/class/trigger is used. This will apply when the Developer Console is actively logging, and for direct creation of TraceFlag records via the Tooling API
3. If you enable system logs for a user, you get debug logs for that user’s next 20 requests.
4. Synchronous and asynchronous Apex tests execute with the default logging levels.
5. If your entry point sets a log level, that log level is used.
   I'm not 100% sure on the position of this last point. Apparently it is for Visualforce requests that include a debugging parameter. Does it make sense for a TraceFlag or system level user log to take precedence?

Answer 1

The ordering has been inconsistent and, in some cases, undefined. We wanted to make it consistent. The order here was the one that was used by most entry points.

Part of the long-term goal of the refactoring we are doing is to make it much less confusing as to what logs were generated and why. We get a lot of investigations due to misunderstanding of the various ways to generate logs and which of those ways takes precedence.

As of today, the DebuggingHeader vanishes after you've made your API call. It generates logs that don't reconcile with the persisted TraceFlag objects in the org. This, in turn, generates customer cases! (e.g., I have a traceFlag saying to log at this level, yet my log is being generated at that level. why?)

One simple solution is to make an API call prior to your request which creates the correct TraceFlag, in place of putting the same information in the DebuggingHeader. This will allow someone looking afterwards to understand what happened and how the log was generated.

We will be making more changes in this area in the coming releases to make this all more sensible and hopefully more flexible for everyone.