Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

addLogListener causes stack overflow and unintended side effects with other Logger instance #114

Open
bawahakim opened this issue Feb 24, 2025 · 1 comment

Comments

@bawahakim
Copy link

bawahakim commented Feb 24, 2025

SDK Affected

AppKit

Describe the bug

When calling addLogListener on ReownCore and logging with Logger of the same event level, the app throws a stack overflow (causes an infinite loop). This is probably due to an issue with the Logger package: SourceHorizon/logger#83. Since it adds a global callback, any instances of the logger will be called by the callback, including the consuming project's logger instance(s).

This causes an issue in our project, because we also use Logger as our logging tool, and calling addLogListener causes important side effects.

There are two important cases:

  1. Logging with a Logger instance within the callback. This causes a stack overflow (callback -> logger -> callback)
  2. Logging with a Logger instance outside the callback. This calls the callback that may not be related to ReOwn (logger -> callback). Although it does not cause a stack overflow, it creates an unintended side effect.

Although appears to be an issue with the Logger package, I chose to report it here to see how solutions could be applied.

Potential solutions:

  1. Migrate to Logger 3.0.0 which seems to fix the issue. The callback should then be added to the local instance rather than the static one. However, 3.0.0 is not officially released, so unsure if stable to use in prod
  2. Adding a middleware logging class that would dispatch the logs appropriately (without Logger). To prevent breaking the internal code or a major refactor, the middleware class would need to use the same method signature, perhaps extending Logger. This class would act as a wrapper to Logger that would also send the event in the callback.
  3. Temporarily: Add a clear identifier in the log callback (e.g. [ReOwn]) so it can be filtered out in the callback Unfortunately, the addLogListener method also appends whatever is added to any log used with Logger instance, since it is global (also another problem). So this solution seems impractical.

To Reproduce

Steps to reproduce the behavior:

  1. Create a Logger instance
  2. Create a app kit modal instance with log level debug
  3. Add a callback with appKitModal.core.addLogListener

Case 1:

  1. Call debug on the logger instance within the addLogListener callback
  2. Initialize appKitModal

Case 2:

  1. Add a print statement in addLogListener callback
  2. Call debug on the logger instance somewhere else in the code

Expected behavior

Case 1: The log should be logged with the logger once, and not cause a stack overflow/infinite loop
Case 2: The print statement should not print when calling debug somewhere else in the code

Reproducible code

final logger = Logger();

final appKit = await ReownAppKit.createInstance(
  projectId: 'projectid',
  logLevel: LogLevel.debug,
  metadata: PairingMetadata(
    name: 'appname',
    description: 'description',
    url: 'https://example.com/',
  ),
);

appKitModal = ReownAppKitModal(
  context: context,
  appKit: appKit,
);

// Case 1
appKit.core.addLogListener(logger.debug);
await appKitModal.init();

// Case 2
appkit.core.addLogListener(print);
await appKitModal.init();
logger.debug("Hi there");
@bawahakim bawahakim changed the title addLogListener causes stack overflow and unintended side effects with other Logger instance addLogListener causes stack overflow and unintended side effects with other Logger instance Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant