Track OrgLimits data on Log__c

[jongpie]

Core Unlocked Package Changes

• Resolved Capture OrgLimits data on Log__c #630 by adding new functionality to track organization limits data, returned by the class System.OrgLimits

  • This data is automatically stored as JSON in the new field Log__c.OrganizationLimits__c

  • You can disable storing this data, using the new LoggerParameter__mdt record StoreOrganizationLimits

  • This data is displayed within a new "Organization Limits" tab on the Log__c flexipage, using a new LWC logOrganizationLimits (shown below). The design of this LWC is intended to mimic the existing formula fields shown on LogEntry__c that are used to track transaction limits.

    

    • For comparison, this image shows the existing formula fields on LogEntry__c that are used to track transaction limits.

      

• Added another new LoggerParameter__mdt record, StoreTransactionLimits, to control if transaction limits are retrieved from the class System.Limits & stored on LogEntry__c

  • Previously, transaction limits were always populated, with no way to disable it - using the System.Limits class does seem to have some overhead (namely, it uses CPU time), so being able to disable this functionality can, hilariously, help to reduce transaction limits usage.

• loggerPageSection LWC changes: Fixed some padding in loggerPageSection.html so it's more consistent with 'real' field section headers

[jongpie]

@jamessimone following up on your comment about OrgLimits.getMap() failing during synchronous tests, I think it's maybe fixed now, kind of?

• I did initially have a relevant flaky test failure - my new test method failed once due to the returned JSON output not matching the expected value. Due to the length of the JSON, the assert message was truncated, so I couldn't see exactly why it didn't match (but calling OrgLimits.getMap() didn't seem to throw an exception). The same test passed during the same build in 1 of the 2 scratch orgs used in the pipeline (the base scratch org), but failed in the other (experience cloud scratch org).
• I then re-ran the build, and was able to successfully run the pipeline for all steps, including running of all tests synchronously and asynchronously, creating a managed package version, and an unlocked package version.
• This known issue sounds relevant to the problem you've had, and it's now marked as "solution delivered".

The 1 flaky test failure seems a little suspicious, but I haven't been able to reproduce it. Do you remember if you were seeing a specific error message before when you tried to use OrgLimits.getMap()?

[jamessimone]

@jongpie let me take a look, at the time I was able to repro the issue with a synchronous test run

[jamessimone]

It seems to work now, great call!

[jongpie]

@jamessimone awesome, thanks for checking!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.05%. Comparing base (5835da6) to head (77982ce).

❗ Current head 77982ce differs from pull request most recent head fe01586. Consider uploading reports for the commit fe01586 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #646      +/-   ##
==========================================
+ Coverage   95.03%   95.05%   +0.01%     
==========================================
  Files          50       50              
  Lines        5624     5663      +39     
==========================================
+ Hits         5345     5383      +38     
- Misses        279      280       +1     

Flag	Coverage Δ
Apex	95.05% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.