logger does not list component type when used in aura component

[ZackFra]

Package Edition of Nebula Logger

Unlocked Package

Package Version of Nebula Logger

v4.13.11

New Bug Summary

Attempted to use the lwc logger in an aura component. Retrieved the logger with the following code and saw that although the component section appeared on the log entry page, it was blank.

component file:

<aura:component implements="flexipage:availableForRecordHome" controller="ComponentLogger">
    <c:logger aura:id="logger"/>
    <lightning:button label="Log" onclick="{!c.log}"/>
</aura:component>

controller file

({
    log: function(component, event, helper) {
		const logger = component.find('logger');
		logger.info('Logging with info');
		logger.saveLog();
    }
})

Observed that the following log entry was created after clicking "Log".

The component section was visible, but not populated.

Suspected this had something to do with the stack being generated in the LWC, but I would think that would've marked this log entry as an LWC if that was the case?

Played around with it for a few hours, modified the code a bit, injected the "stack" attribute with a stack generated from the aura component and passed down, still saw the same results.

[ZackFra]

Worth noting, this issue was also raised today by another person on Reddit. They found that when importing the component directly, in an LWC, it worked correctly, but seemed to work as I've described when grabbing the injected logger component via a template query.

https://www.reddit.com/r/SalesforceDeveloper/comments/1czqs5t/nebula_logger_with_lwcs/

[jongpie]

@ZackFra I've been looking into this issue some more, and I think there's some other aspect related to this problem - I'm also testing with v4.13.11, and using the included Aura demo component and the included legacy LWC demo component, everything functions correctly for me. It captures & stores the component name & function. I've also tested this in both Firefox & Chrome, and everything works in both browsers, so I haven't found a way to reproduce this issue.

But you're experiencing this issue + so is the person on that Reddit post (thanks for providing that!) + this discussion seems to be the same thing, there's definitely something going on, but I can't make sense of why it only happens for some people/orgs.

Let me know if you have any thoughts on what could be causing the difference in behavior. I'll keep trying to reproduce this issue too, maybe it's related to some org setting?

[ZackFra]

@jongpie

Interesting. It seems to have something to do with the context in which it's called.

So the two scenarios I've found that trigger this issue if when it's an aura component on an Experience Cloud site, and when its an aura component embedded in a lightning record page.

I just sprung this up in a new trailhead to confirm the lightning record page scenario with the recipe from the repo.

If you change the recipe to implement "flexipage:availableForAllPageTypes", put it on the lightning record page for Accounts, then click the button to trigger the log, you see this:

[jongpie]

@ZackFra, I finally had some time to look into this further, and you were 100% correct that it's based on the context in which it's called. In particular, 2 aspects of the context seem to matter:

• The Salesforce context of where the logger LWC is used, such as lightning__RecordPage and lightning__Tab (here's the full list of targets available)
  • I typically have been testing just with lightning__Tab, which seems to work correctly - but other contexts currently don't, so I previously was not able to recreate some of the issues.
• The browser of the user. I found a few differences in the stack traces generated by Firefox vs Chrome, which resulted in logging in Chrome being "more" broken than in Firefox.
  • I typically use Firefox, so I previously was not able to recreate some of the issues.

Setting Up Some Tests

To try to get a better understanding of what scenarios are having issues, I spent some time setting up metadata in a scratch org & tested the JS stack traces that were generated in several contexts + browsers. Below are the scenarios & results of what I tested, using the latest version of Nebula Logger (without your fixes in PR #692)

• ✅ - everything works as expected, a "valid" JS stack trace is created & successfully parsed by Nebula Logger
• ❌ - either the generated stack trace wasn't valid, or Nebula Logger wasn't able to parse it

Salesforce Context	Browser	Import createLogger() into LWC	Embed logger in LWC markup	Embed logger in Aura markup
lightningCommunity__Page in an Aura runtime Experience Cloud site	Chrome	❌ Generated stack trace in connectedCallback() is missing some critical details ❌ Existing parsing logic is broken for other contexts	❌ Generated stack trace in connectedCallback() is missing some critical details ❌ Existing parsing logic is broken for other contexts	❌ Generated stack trace is missing some critical details
lightningCommunity__Page in an Aura runtime Experience Cloud site	Firefox	✅	✅	❌ Generated stack trace is missing some critical details
lightningCommunity__Page in an LWR Experience Cloud site	Chrome	❌ Generated stack trace in connectedCallback() is missing some critical details ❌ Existing parsing logic is broken for other contexts	❌ Generated stack trace is missing some critical details	ℹ️ Not feasible - LWR can't use Aura components
lightningCommunity__Page in an LWR Experience Cloud site	Firefox	✅	✅	ℹ️ Not feasible - LWR can't use Aura components
lightning__RecordPage	Chrome	❌ Existing parsing logic is broken	❌ Generated stack trace is missing some critical details	❌ Generated stack trace is missing some critical details
lightning__RecordPage	Firefox	✅	✅	✅
lightning__Tab	Chrome	❌ Existing parsing logic is broken	❌ Generated stack trace is missing some critical details	❌ Generated stack trace is missing some critical details
lightning__Tab	Firefox	✅	✅	✅

Test Results Summary

There are still several other targets available that I haven't tested yet, but my guess is that there would be some similar issues with certain targets.

But based on the testing results I have so far, it seems like there are 2 main issues:

1. Stack trace parsing only works for Firefox: The existing logic for stack trace parsing only accomodates Firefox's format - for all of the stack traces generated in Chrome, I found 1 or more issues with how the stack trace is being parsed.
2. Some JS stack traces are missing critical details: The stack traces generated in certain contexts sometimes don't contain the relevant info needed to determine the origin details. This is especially a problem when using Chrome + Aura components.

Next Steps

I think that several of the existing issues can be fixed easily/have been fixed by your changes in #692, but there are a few contexts that I think still have some problems. There are a couple of things that I'm planning to do next:

• Test some additional contexts & browsers, and test your changes in PR bugfix/aura-logging #692
• Merge some metadata changes that make it easier to test logger in these different contexts - it took me a while to setup a scratch org with a flexipage & Experience Cloud sites, and I want it to be much easier to test this stuff in the future, so I'll be merging some extra test metadata into the repo

Resolving all of the scenarios might end up taking a few releases to fully address everything, but my hope is to release a new version ASAP that addresses at least several of the "quick-fix" issues.

[jongpie]

@ZackFra another update on this - I've spent the last few weeks doing additional testing, and exploring options on how to resolve some of the (several) bugs.

• I've created PR Overhauled JavaScript stack trace parsing #727 that (I think) resolves most of the issues with JS stack trace parsing. It moves all of the parsing logic (for JS stack traces) from Apex to instead happen in JavaScript
  • There are still some issues related to createLogger() being an async function, but I'll explore this issue more in the future
• I'm planning to close your PR bugfix/aura-logging #692 (and use Overhauled JavaScript stack trace parsing #727 instead), but your feedback on this issue + your changes in your PR have been incredibly helpful in getting to the bottom of these issues, so thank you for all of the time you have spent working on this

I'm hoping to merge #727 this week.

[jongpie]

JavaScript stack trace parsing has now been fixed (I hope 😅 ) in release v.4.13.17, except for one remaining known issue #728.

Thanks again for all of your help with this!

[ZackFra]

@jongpie No problem man! Glad I could help! Love the Nebula Logger by the way, keep up the good work! :)