Weird behavior of debugging from test method

[ketchyn]

I have already posted the similar problem.https://bitbucket.org/RoseSilverSoftware/illuminatedcloud/issues/369/unable-to-step-through-breakpoints-in But it seems like problem remains I have been suggested to check logs level of debug configuration, and the weird thing is that sometimes debugger is being lauched properly, and in some case it fails(go to the first line of test class and the next step finishes debug mode) And I haven't found out what it depends on yet.

Aslo sometimes i'm getting the folowing error

[Scott Wells]

It sounds like in general the issue has to do with the maximum allowed debug log size of 2MB. Unfortunately when a process' log gets larger than that size, it's truncated in some random location...sometimes at the beginning and sometimes at the end. Depending on where it's truncated at any given time, you might have some success using that log for debugging, it may go to the first line that it thinks is executable based on incomplete log (going to the first line and then going nowhere from there), or it may fail to start altogether (several ways this can occur).

Take a look at the log being used to drive debugging. If it doesn't start with a valid log header showing the log levels and doesn't end saying that process has wrapped up, it's being truncated. You may or may not see the MAXIMUM DEBUG LOG SIZE REACHED error depending on how/where it was truncated. If you don't have a full log, your only options are to lower the logging levels and use checkpoint-based debugging (no line-by-line stepping) or to come up with a way to debug the interesting part of the process in isolation.

Let me know if this doesn't help or make sense.

[ketchyn]

It seems like the problem not at this point. When I'm launching debug related log is about 12 kilobytes

If it's needed I can give you creds of my org in order to test it

[Scott Wells]

If you have an org that shows the issue and I can connect to it without concerns, that would be the most expedient, but if the org contains sensitive/private data at all, I'd prefer to reproduce it in isolation. I'm happy to take a look either way. Just let me know what makes the most sense to you.

[ketchyn]

Ok, its a test dev org, so it doesn't contains any private data, but of course it would better if all data remain) So how can I contact you and send creds in private message?

[Scott Wells]

You can email the creds to me.

[Scott Wells]

After chatting out-of-band a bit, the main takeaway here is that two things can be obstacles to getting usable logs (assuming the generated log wouldn't be truncated): 1) other trace flags/log levels that end up superseding the one managed by IC, e.g., trace flags created by IC before switching to the same one managed by the Dev Console; 2) a situation where the correct log wouldn't be generated until a trace flag was added to the test class itself. I'm going to add item 1 to the FAQ since I don't think it's IC's responsibility to remove other trace flags (at this point, even the ones that IC had previously created). As for item 2, it's contrary to Salesforce's own documentation where the Dev Console's trace flag should take top priority. I've asked Salesforce about why this might occur but haven't heard anything yet. For now I'm going to resolve this issue and, if I hear something definitive from Salesforce about why this is happening, I'll create a dedicated issue to deal with that.

[ketchyn]

Hello, thanks for your feedback, I,m glad to hear you are working on this issue, Hope you will finde how to overcome those 2 obstacles)