[SalesForce] Visual Studio Code – Developer Console

Just so I understand, you did the following steps:

1. Set the monitored portal users in the Debug Log Page
2. Open the developer console and unchecked "Show my current logs only" (sort by time so new logs show up on top)
3. Executed apex as the portal user

After those steps, a log should appear in the developer console or the Debug Logs page. If no log appeared with the user in the monitored users list, then you should open a case.

Let me take a minute to go over how Trace Flags are used. Trace Flags have 3 different fields we care about.

• scopeId : The scope at which we generate a "debug" or "system" log. The only difference is the way the logs are stored. Supports either a user id, empty id, or null.
• tracedEntityId : The entity we want to trace. Either a user id or an apex class/trigger.
• expirationDate : When we should we stop logging.

Monitored users (debug logs) create a trace flag with a scopeId = null and tracedEntityId = "id of user to monitor".

Developer console (system logs) create a trace flag with a scopeId = "id of you" and traceEntityId = "id of you". If you close the developer console, it will expire just that one trace flag so system logs stop being generated. This is what happens when the developer console is open for too long being "idle" is the trace flags expire, so resume will re-enable the trace flags. The log panel in the developer console only shows apex logs create by you since the console was open or 'Clear'ed. When you uncheck "Show my current logs only" it should show all the apex classes on the org, regardless of user or type.

If you set up class level filtering, it will create a trace flagwith the tracedEntityId to the class you want, and will be applied for all users (debug and system).

When I say "create" above, I really mean it will check if one already exist. If so, it will update the expiration date. If not, it will create one. That known issue specific to monitored users in the Debug Logs page is because it wasn't setting the expiration correctly. That is why deleting it works, because then it will create a new one.

The entire Developer Console is built in JavaScript, which, despite recent advances in software and hardware, remains relatively slow in many cases compared to native applications. One place you'll notice this problem is in cases where a ton of work has to be done in a short period of time. Try setting your debug logs to the maximum setting, then try using the full perspective (Debug > Switch Perspective).

If you are debugging a log near 2MB, your browser will probably freeze momentarily trying to render the log. It's really not designed to do that, but we developers try anyways. Also, while in a maximum perspective, change the size of your window, and observe how it appears to stutter or freeze on the inside.

Now, to get to my point, when you're running a batch with say, 10,000 batches, the log table has to be redrawn many times per second potentially, with rapidly increasing memory usage and tons of elements. Your browser will try to accommodate the request to constantly redraw, eventually slowing to a crawl. You'll find that not only the Developer Console unresponsive, but the page you launched the Developer Console will also act jittery and/or freeze. This is because of JavaScript's single-thread model.

Run batches as an alternate user, when possible, or keep such batches small. Clear your logs frequently, as well, since once you get to a couple of hundred logs, you'll notice a pretty sharp decline in performance. You'll probably eventually need to close the window every so often and/or all of the files you're working on, or the console will eventually become slow as things keep piling on, such as the progress sub-tab, which can accumulate thousands of items of its own.