Parsing large debug logs hangs IDE

[Jurgis Salna]

Parsing large (18mb or so) seems to be hanging IDE.
If I click Cancel at the right moment, immediately after Raw version appears - it is fine
If I miss it and click after that seemingly never completes and gets suck at Parsing log body.

IMO seems it fails at getting tree representation (personally I rarely use Tree view so IMHO it would be better if that was deferred until user opens Tree tab - if possible at all)

[Jurgis Salna]

Offending log file

[Scott Wells]

Thanks for attaching the log. I'll take a look at it. In the past it's been less the parsing that takes time and more actually populating/drawing the initial tree. I'll be interested to see what's going on with this one as I've certainly worked with ~20MB logs with very few issues. I wonder if there's something special about this one.

[Scott Wells]

Yeah, what’s going on here just seems to be a bug with how it parses the log into a tree. I’ll dig in and figure that out, but once resolved, even the tree should be properly parsed/populated in pretty short order.

[Scott Wells]

Okay, this seems to be the issue:

17:13:06.820 (12852607464)|CALLOUT_REQUEST|[99]|<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Header><SessionHeader xmlns="http://soap.sforce.com/2006/04/metadata"><sessionId>SESSION_ID_REMOVED</sessionId></SessionHeader></env:Header><env:Body><updateMetadata...

For some reason the log is jamming the full SOAP request envelope into what should be a simple callout name, e.g., the following as another callout request from the log:

17:13:05.788 (12672492420)|CALLOUT_REQUEST|[1653]|System.HttpRequest[Endpoint=https://data-site-4452-dev-ed.scratch.my.salesforce.com/services/data/v58.0/limits/, Method=GET]

IC2 is getting stuck trying to extract a useful name from that SOAP envelope.

Not sure why they’re doing that, but it should be pretty simple to address.

[Scott Wells]

Fix implemented. Arbitrarily large CALLOUT_REQUEST entries are now truncated at 200 characters – which comfortably fits (most such) entries which have properly formatted callout endpoints – and parsing the log into a tree and displaying it is now nearly instantaneous with the provided log.

[Jurgis Salna]

Does truncation apply to tree only or to raw too?

[Scott Wells]

The truncation is only for the tree and really only for purposes of creating a “node name” for the CALLOUT_REQUEST node in the tree when it has a log entry as shown above. The original log information – including how it’s displayed in the raw view – is unaltered.