Feature Request: Always store HTTP Request/Response regardless of log level

[jvega-intakedesk]

I have specific requirements for always storing the HTTP Request and Response data, and I’m trying to see if my existing NebulaLogger setup can handle this.

Right now, I know there are methods like setHttpRequestDetails(...) and setHttpResponseDetails(...), which correctly capture what I need. However, these methods are usually tied to a given log level. My need is to always log the HTTP request and response, regardless of the current logger settings or log level.

Is there a way to do something like Logger.http("logging an HTTP request").setHttpRequestDetails(...) that would bypass or override the log level settings so this data is always captured? If not, is there a recommended approach for implementing such a feature?

Thanks for any insight or suggestions!

[jongpie]

Hi @jvega-intakedesk - you should be able to do this already with any log entry, using one of the overloads for Logger.newEntry(). Essentially, you provide a boolean value to indicate if the log entry should be saved (regardless of the user's configured logging level).

Here's an example of how to use it:

// You can decide if the the log entry is always saved (by always setting it to true),
// or if you could use some custom logic to determine the boolean value.
Boolean shouldSave = true; 
Logger.newEntry(System.LoggingLevel.FINEST, 'Another Message', shouldSave)
    .setHttpRequestDetails(new System.HttpRequest());
Logger.saveLog();

Hope this helps, but let me know if you have any follow up questions!

[jvega-intakedesk]

Thanks @jongpie - This is exactly what I am looking for and I can chain setRecordId to add additional context.

[jvega-intakedesk]

@jongpie – I believed I had tested this, but the developers noticed that although newEntry's shouldSave method allows inserting into the log's buffer by bypassing the log level, the platform event subscriber appears to run another check in filterLogEntryEventsToSave, ensuring the logging level matches. As a result, the log entry isn’t actually saved. Is this expected? If so, are there any other options to persist the entry regardless of the log level setting?

[jongpie]

@jvega-intakedesk out of curiosity, are you using the unlocked package (no namespace) or the managed package (Nebula namespace)?

[jvega-intakedesk]

@jongpie We are using the unlock package.

[jongpie]

Perfect - the unlocked package has a much faster release cycle than the managed package, so I'll (more than likely) patch this in the unlocked package first. I'll keep you posted on my progress - in the meantime, if you need anything else, let me know!

[jongpie]

@jvega-intakedesk I had a little time this evening to look into this, and I think I have a fix (nearly) ready in PR #857 🥳

I'll do some more testing this week to ensure this fully handles the issue - if everything looks good to go, I'll try to merge & release this (in the unlocked package) either later this week or sometime next week.

[jongpie]

@jvega-intakedesk this has been released in v4.15.9! Thanks again for the help with this, and let me know if you/your team run into any other issues.