Thanks to @vikashkrml for working on this release in PR #892 🥳👏

Core Unlocked Package Changes

Fixed #760 by adding auto-capturing of Apex cursor transaction limits for rows & fetch calls, stored in new fields on LogEntryEvent__e & LogEntry__c

• Added 4 new number fields on both LogEntryEvent__e and LogEntry__c to capture Apex cursor limit values returned by the Limits class

  1. LimitsApexCursorFetchCallsUsed__c 🟰 System.Limits.getFetchCallsOnApexCursor()
  2. LimitsApexCursorFetchCallsMax__c 🟰 System.Limits.getLimitFetchCallsOnApexCursor()
  3. LimitsApexCursorRowsUsed__c 🟰 System.Limits.getApexCursorRows()
  4. LimitsApexCursorRowsMax__c 🟰 System.Limits.getLimitApexCursorRows()

• Added 2 new formula fields on LogEntry__c to show the percentage used of both Apex cursor fetch calls and Apex cursor rows. This formula fields provide the same functionality as the other existing formula fields on LogEntry__c shown on the Transaction Limits tab of the flexipage

  

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.16.4...v4.16.5

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04tKe0000011N4KIAU
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011N4KIAU
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011N4KIAU

Core Unlocked Package Changes

Fixed #870 (reported by @dominykasvitkus) by updating the logger LWC initialization message to only print when JavaScript console logging is enabled via LoggerSettings__c. Also resolved some test isolation issues in logger.test.js + test improvements + code cleanup:

• Updated loggerService.js to only call console.info() with an init message ('logger component initialized') when console logging is enabled via LoggerSettings__c.IsJavaScriptConsoleLoggingEnabled__c
• Replaced enableSystemMessages() and disableSystemMessages() in loggerService.js with a new static variable LoggerService.areSystemMessagesEnabled (intended for internal-use only)
• Updated logger.test.js to reset LoggerService.hasInitialized and LoggerService.areSystemMessagesEnabled static variables in beforeEach() (instead of afterAll())
• Switched to using jest.resetAllMocks() instead of jest.clearAllMocks() in logger.test.js for better test isolation
• Updated all test functions to consistently use all 3 logger creation methods (createLogger, getLogger, and getMarkupLogger)

Also include a 🤏 liiiiiiitle bit of scope creep:

• Updated all Jest tests to import createElement from '@lwc/engine-dom' (instead of 'lwc')
• Updated the project's threshold for code coverage in codecov.yml to compensate for the lower code coverage in LWC tests for now (currently around ~86%). Eventually, tests & code coverage for LWC will be improved - but for now, the constant pipeline alerts from codecov.io aren't particularly helpful 😅
• Cleaned up a small code block in LogBatchPurger using the null coalescing operator (??) to reduce the lines of code needed
• Corrected the label on field LoggerScenarioRule__mdt.IsLogAssignmentEnabled__c to use the term Logger Scenario, instead of the deprecated term Log Scenario

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.16.3...v4.16.4

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04tKe0000011MyWIAU
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011MyWIAU
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011MyWIAU

Core Unlocked Package Changes

Fixed #807 by adding the ability to declaratively configure the default batch size in LogBatchPurger. This can be used to reduce the batch size to help with mitigating Apex heap size exceptions that can sometimes happen in the LogBatchPurger job when deleting larger volumes of logging data. And making it now configurable makes it easy to quickly change it in orgs as needed.

• Add new LoggerParameter__mdt record LogBatchPurgerDefaultBatchSize
• ℹ️ The new default batch size for LogBatchPurger is now 500 (and now controlled via LogBatchPurgerDefaultBatchSize).
• Previously, 2000 was used, but 500 is the new default to try to help avoid Apex heap size exceptions. If desired, you can update the record's Value__c field to 2000 to restore the previous value/behavior used prior to this release

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.16.2...v4.16.3

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04tKe0000011Mr1IAE
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011Mr1IAE
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011Mr1IAE

Slight tweak to origin location stack trace parsing in Apex to improve how origin location is displayed:

• before, it was possible for External entry point to be reported as the origin location even when a valid stacktrace was present beneath that text
• if there is a valid stacktrace line beneath the words External entry point, those will be used as the origin location from now on

Noticed while we were cross-checking the following issue: jamessimone/apex-rollup#683 (comment)

Core Unlocked Package Changes

Bundled Data Masking Rules Bugfixes + New American Express (AMEX) Masking Rule

• Bugfix: Fixed issues in the regular expressions (regexes) used in the 3 existing LogEntryDataMaskRule__mdt records (stored in the field SensitiveDataRegEx__c). The previous regexes were too aggressive, and would sometimes incorrectly mask substrings of non-credit card & non-social security number values.
  • SocialSecurityNumber
  • MastercardCreditCardNumber
  • VisaCreditCardNumber
• Enhancement: Added a new bundled record in LogEntryDataMaskRule__mdt for American Express (AMEX) credit card numbers - AmericanExpressCreditCardNumber (similar to the existing rules for Visa & Mastercard)

Data Masking Bugfixes + Truncation Bugfixes + New *Truncated__c Boolean Fields

• Bugfix: Fixed #695 by adding another round of string truncation after applying data masking to fix issues where string values could still be too long for the corresponding fields

  • Context: Some data masking rules can (intentionally) cause a text value's length to increase. For example, social security numbers are formatted with - dashes when masked, so values like 123456789 (9 characters) are 2 characters longer when masked as ***-**-6789 (11 characters).
  • In previous versions of Nebula Logger, text was truncated, then masked. With a combination of long text values + matching data to mask, the resulting text value could be too long. This was especially a problem for the Message__c field in several orgs, but the same issue could/did happen with several other text fields.
  • In this release, the text is truncated again after masking to ensure the data will fit into the corresponding field.

• Optimization: Refactored some duplicated logic in LogEntryEventBuilder for truncating + masking various text values

  • There are several fields being masked + truncated (and more fields will probably be added in the future), and the existing code had a lot of code duplication happening.

• Enhancement: Added several new *Truncated__c boolean fields on both LogEntryEvent__e & LogEntry__c for some data points where it would be helpful to have the context that data has been truncated. There are 5 sets of new fields included:

  1. LogEntryEvent__e.HttpRequestBodyTruncated__c ➡️ LogEntry__c.HttpRequestBodyTruncated__c
  2. LogEntryEvent__e.HttpResponseBodyTruncated__c ➡️ LogEntry__c.HttpResponseBodyTruncated__c
  3. LogEntryEvent__e.RecordJsonTruncated__c ➡️ LogEntry__c.RecordJsonTruncated__c
  4. LogEntryEvent__e.RestRequestBodyTruncated__c ➡️ LogEntry__c.RestRequestBodyTruncated__c
  5. LogEntryEvent__e.RestResponseBodyTruncated__c ➡️ LogEntry__c.RestResponseBodyTruncated__c

• Enhancement: Updated the LogEntryRecordPage flexipage to add the new *Truncated__c boolean fields on LogEntry__c (mentioned above, and shown below)

  • These fields are configured to only show on the page when true, similar to the behavior used for the existing *Masked__c fields, like LogEntry__c.MessageMasked__c & LogEntry__c.RecordJsonMasked__c

  

  

  

  

  

Pipeline Improvements for extra-tests Directory

• DevOps/Pipeline Improvement: Added new pipeline-only test classes with integration tests to validate that the custom metadata type (CMDT) records bundled with Nebula Logger work as expected
  • This includes validating records in LogEntryDataMaskRule__mdt, LoggerParameter__mdt, LoggerSObjectHandler__mdt, and LogStatus__mdt
  • Since orgs can choose to modify or delete the bundled CMDT records, this level of testing needs to happen just in the pipeline
• Re-organized the Apex test classes + metadata in nebula-logger/extra-tests to make it a little more clear what everything is being used for. The number of files has grown a lot over the last few years, so a little cleanup was needed.
  • This directory's metadata is only used by the pipeline to more thoroughly test some features & metadata that's bundled with Nebula Logger - none of it is included when installing Nebula Logger, so these changes should not have any direct impact to people using Nebula Logger.

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.16.0...v4.16.1

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04tKe0000011MXEIA2
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011MXEIA2
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04tKe0000011MXEIA2

🧙‍♂️An open source release is never late, nor is it early. It arrives precisely when it means to. And also when I have the time to work on it. 🧙‍♂️

A huge thanks goes to everyone that's contributed to this release over the last several months! There has been a great mix of bug reporting, features requests, discussions + feedback, and code contributions. This has all been incredibly helpful in delivering some great enhancements this release. So thanks again to everyone that's helped!

Managed Package Release - v4.16.0

This release is for both the unlocked package (as always), as well as the managed package! You can see everything that's changed between v4.15.0 and v4.16.0 for the managed package by reviewing:

• The v4.16.0 milestone to see all of the issues & pull requests that are included in the this release.
• The diff between v4.15.0 and v4.16.0 to see all of the code & metadata changes that have been committed since the last managed package release.

Apex Logging Enhancements

• ✅Release v4.15.2 - Added Support for Logging Instances of Database.EmptyRecycleBinResult and List<Database.EmptyRecycleBinResult> by @TrangOul and @jongpie (PR #806) → closed issue #804 reported by (also) @TrangOul

  • Add new instance method overloads in Nebula.LogEntryEventBuilder for setDatabaseResult() to support logging instances of Database.EmptyRecycleBinResult and List<Database.EmptyRecycleBinResult>

    global Nebula.LogEntryEventBuilder setDatabaseResult(Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global Nebula.LogEntryEventBuilder setDatabaseResult(List<Database.EmptyRecycleBinResult> emptyRecycleBinResults);

  • Added new static method overloads in Logger to make it easier to log instances of Database.EmptyRecycleBinResult and List<Database.EmptyRecycleBinResult>

    global static Nebula.LogEntryEventBuilder error(Nebula.LogMessage logMessage, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder error(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder warn(Nebula.LogMessage logMessage, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder warn(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder info(Nebula.LogMessage logMessage, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder info(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder debug(Nebula.LogMessage logMessage, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder debug(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder fine(Nebula.LogMessage logMessage, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder fine(Nebula.LogMessage logMessage, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder finer(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder finer(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder finest(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder finest(String message, Database.EmptyRecycleBinResult emptyRecycleBinResult);
    global static Nebula.LogEntryEventBuilder logDatabaseErrors(System.LoggingLevel loggingLevel, Nebula.LogMessage logMessage, List<Database.EmptyRecycleBinResult> emptyRecycleBinResults);
    global static Nebula.LogEntryEventBuilder logDatabaseErrors(System.LoggingLevel loggingLevel, String message, List<Database.EmptyRecycleBinResult> emptyRecycleBinResults);

• ✅Release v4.15.10 - Approval Results Logging by @TrangOul, @jamessimone, and @jongpie (#850) → closed issue #844 reported by @PawelWozniak

  • Added new setApprovalResult() methods in Nebula.LogEntryEventBuilder for logging instances of the standard Apex classes Approval.LockResult, Approval.ProcessResult, Approval.UnlockResult, as well as lists of each class

    global Nebula.LogEntryEventBuilder setApprovalResult(Approval.LockResult lockResult);
    global Nebula.LogEntryEventBuilder setApprovalResult(Approval.ProcessResult processResult);
    global Nebula.LogEntryEventBuilder setApprovalResult(Approval.UnlockResult unlockResult);
    global Nebula.LogEntryEventBuilder setApprovalResult(List<Approval.LockResult> lockResults);
    global Nebula.LogEntryEventBuilder setApprovalResult(List<Approval.ProcessResult> processResults);
    global Nebula.LogEntryEventBuilder setApprovalResult(List<Approval.UnlockResult> unlockResults);

  • Note: for now, the decision has been made to not provide overloads in Nebula.Logger for logging the approval classes - this is a little different from logging Database result classes, where Nebula.Logger does provide static method overloads. See this related comment for more details on why this decision was made for Approval result classes.

  • Example usage:

    SObject someRecord = [SELECT Id FROM Account LIMIT 1];
    Approval.LockResult lockResult = Approval.lock(someRecord);
    
    // The builder's new method overloads setApprovalResult() can be called to capture approval details
    Nebula.Logger.debug('Locked record for approval', someRecord)
        .setApprovalResult(lockResult);
    Nebula.Logger.saveLog();

  • The approval result data is stored in the existing set of DatabaseResult* fields on LogEntry__c like LogEntry__c.DatabaseResultType__c, shown below:

    

CallableLogger / OmniStudio Logging Enhancements

• ✅🐞Release v4.15.6 - OmniStudio Logging Enhancements by @jamessimone (PR #835) → closed issue #814 reported by @j-fischer while working on some related enhancements in rflib
  • Closed #814 by adding a new tryCatch callable method for OmniStudio within CallableLogger
  • Fixed a System.TypeException issue in OmniStudio when attempting to add tags to a log entry within CallableLogger
  • Docs: added some explanatory comments for the OmniStudio-specific code within CallableLogger

Bugfixes

• 🐞Release v4.15.7 - Fixed Stacktrace Parsing & Reduced logger.test.js by @jamessimone (PR #840) → closed issue #780 reported by @jongpie

  • Fixed an issue in loggerStackTrace.js that would cause an unintended exception when there isn't a valid JavaScript stack trace
    • This issue previously could happen when logging within the managed package, as well as in some browser configs that have more restrictive settings enabled.
  • Added @api decorator to the the function logger.setField() so that it can be used when logging in Aura components.
    • This function was added in release v4.14.4, but wasn't previously accessible by Aura components.
  • Closed #780 by cleaning up logger.test.js, resulting in, 1,400 lines of JavaScript code being removed! 🧹

• 🐞Release v4.15.4 - FlowLogger Exception Message Handling by @jamessimone (PR #828) → closed issue #827 reported by @shuylern & @andrewofornikar via discussion #823

  • Fixed #827: FlowLogger now properly truncates the LogEntryEvent__e.ExceptionMessage__c field. Previously, long values would have caused an exception & prevented the corresponding LogEntryEvent__e from being properly published.

• 🐞Release v4.15.5 - Bugfix for AuthSession with Null LoginHistory Exception by @camillerev (PR #831)

  • Added safe navigation operator on LoginHistory from AuthSession records to avoid a NullPointerException
  • Fixed an issue where Log__c.ImpersonatedBy__c was not set when AuthSession data is queried async

• ✅🐞Release v4.15.9 - Bugfix: Entry Save Override Is Not Always Used by @jongpie (PR #857) → fixed issue #856 reported by @jvega-intakedesk via discussion #855

  • Added new fields EntrySaveReason__c on LogEntryEvent__e & LogEntry__c to explicitly track why an entry is saved. This new field is now also used in LogEntryEventHandler.filterLogEntryEventsToSave() to ensure these type...

Thanks goes to @PawelWozniak for suggesting this enhancement (issue #844), and to @TrangOul & @jamessimone for working on the changes!

Core Unlocked Package Changes

• Added new setApprovalResult() methods in LogEntryEventBuilder for logging instances of the standard Apex classes Approval.LockResult, Approval.ProcessResult, Approval.UnlockResult, as well as lists of each class. Developers can use the new method overloads with something like this:

  SObject someRecord = [SELECT Id FROM Account LIMIT 1];
  Approval.LockResult lockResult = Approval.lock(someRecord);
  
  // The builder's new method overloads setApprovalResult() can be called to capture approval details
  Logger.debug('Locked record for approval', someRecord)
      .setApprovalResult(lockResult);
  Logger.saveLog();

• The approval result data is stored in the existing set of DatabaseResult* fields on LogEntry__c like LogEntry__c.DatabaseResultType__c, shown below:

  

Installation Info

Core Unlocked Package - no namespace

Full Changelog: v4.15.9...v4.15.10

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015pGeQAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015pGeQAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015pGeQAI

Thanks again to @jvega-intakedesk & team for reporting issue #856 (via discussion #855), helping to test PR #857! 🥳

Core Unlocked Package Changes

Quick context on this release: in Apex, developers have the ability to force certain entries to always save, even if the entry's logging level doesn't meet the current user's logging level (e.g., a DEBUG entry can be made to always save, even if the user's logging level is set to INFO). This is useful for a lot of teams in a lot of situations (such as auditing/monitoring requirements), and has been a feature for a loooong time.

But, @jvega-intakedesk & team recently pointed out that although the LogEntryEvent__e platform events are successfully published, the corresponding LogEntry__c records are inadvertently not created. This release corrects this issue with a few changes:

• Added new fields EntrySaveReason__c on LogEntryEvent__e & LogEntry__c to explicitly track why an entry is saved, with 2 possible values:

  1. Logging Level Met: indicates that the entry was saved because the entry's specified logging level meets the logging user's configured logging level settings, stored in LoggerSettings__c.LoggingLevel__c.
  2. Save Overridden: indicates that the entry was saved because a developer has overridden in code the shouldSave flag for the entry. This is done by developers to ensure certain entries are always logged, regardless of the user's configured logging level.

• Updated LogEntryEventBuilder and LogEntryEventHandler to set the new fields on LogEntryEvent__e and LogEntry__c.

  • ℹ️ Going forward, all new LogEntryEvent__e and LogEntry__c records will now have a value populated in EntrySaveReason__c.
  • ⚠️ Existing LogEntry__c records will still have null - no changes are being introduced to backfill the data.

• Updated the logic in LogEntryEventHandler.filterLogEntryEventsToSave() to check the value of the new field LogEntryEvent__e.EntrySaveReason__c. Any entries with a save reason of Override are always saved in LogEntry__c (which is the piece that directly fixes #856).

• The flexipage LogEntryRecordPage has also been updated to display the new field LogEntry__c.EntrySaveReason__c when it's populated. For any existing LogEntry__c records with a null value, the flexipage will hide the field.

  

  

Installation Info

Core Unlocked Package - no namespace

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015pGKQAY
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015pGKQAY
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015pGKQAY

• Fixes #847 by adding Log__c.ParentLogTransactionId__c custom index

This is a small release that will help unblock our friends at Google. See the prior release for more!

Thanks again to @jamessimone for working on yet another awesome release! 🥇 (See PR #835)

Core Unlocked Package Changes

• Fixed an issue in LoggerStackTrace.js that would cause an unintended exception when there isn't a valid JavaScript stack trace.
  • This issue previously could happen when logging within the managed package, as well as in some browser configs that have more restrictive settings enabled.
• Added @api decorator to the the function logger.setField() so that it can be used when logging in Aura components.
  • This function was added in release v4.14.4, but wasn't previously accessible by Aura components.
• Closed #780 by cleaning up logger.test.js, resulting in, 1,400 lines of JavaScript code being removed! 🧹
  • Over the years, 3 different approaches have been used within Nebula Logger to provide JavaScript logging. The older approaches are considered deprecated, but are still supported - so automated testing is critical to ensuring all approaches still work.
  • Previously, logger.test.js had test cases duplicated for all 3 approaches, making it a nightmare to maintain.
  • In this release, @jamessimone streamlined the tests so that the same test cases are now used to validate all 3 approaches.

Installation Info

Core Unlocked Package - no namespace

• SF CLI: sf package install --wait 20 --security-type AdminsOnly --package 04t5Y0000015pEnQAI
• Sandbox: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015pEnQAI
• Production: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000015pEnQAI