Feat: Logger service background integration #406
Conversation
WalkthroughCentralized logging was integrated across the app: local Changes
Sequence Diagram(s)sequenceDiagram
participant Main as main()
participant LogReceiver as IsolateLogReceiver
participant Background as Background Isolate
participant LoggerSvc as logger_service
Main->>LogReceiver: initIsolateLogReceiver()
LogReceiver-->>Main: provide loggerSendPort
Main->>Background: start isolate (payload includes loggerSendPort)
Background->>LoggerSvc: log via IsolateLogOutput -> sends to loggerSendPort
LoggerSvc->>LogReceiver: receive log messages
LogReceiver->>Main: forward/record logs (console/file/UI)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (2)**/*.{dart,flutter}📄 CodeRabbit inference engine (CLAUDE.md)
Files:
**/*.dart📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧠 Learnings (13)📚 Learning: 2025-11-27T12:10:26.407ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.081ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-10-14T21:12:06.887ZApplied to files:
📚 Learning: 2025-05-06T15:49:26.443ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-05-08T16:29:52.154ZApplied to files:
📚 Learning: 2025-11-27T12:10:12.082ZApplied to files:
📚 Learning: 2025-07-20T23:33:17.689ZApplied to files:
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (4)
✏️ Tip: You can disable this entire section by setting Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
BraCR10
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
lib/background/mobile_background_service.dart (1)
42-51: Remove duplicate'start'invocation to prevent redundant settings transmission.The
'start'command is invoked twice with identical payloads:
- In the
on-startlistener (lines 44-46) whenservice.startService()triggers the event- In
_startService()after confirming the service is running (lines 156-159)Both send the same payload (
settingsandloggerSendPort). When_startService()callsservice.startService(), it triggers theon-startlistener, causing the first invocation. Then the method waits for the service to be running and invokes'start'again. Remove one of these invocations to avoid redundant command execution.
🤖 Fix all issues with AI agents
In @docs/LOGGING_IMPLEMENTATION.md:
- Line 30: The documentation contains a typo: change "subclases" to "subclasses"
in the line referencing AbstractMostroNotifier and its implementations; open
docs/LOGGING_IMPLEMENTATION.md, find the line with "AbstractMostroNotifier +
subclases (AddOrderNotifier, OrderNotifier)" and correct the spelling to
"AbstractMostroNotifier + subclasses (AddOrderNotifier, OrderNotifier)" so the
class names (AbstractMostroNotifier, AddOrderNotifier, OrderNotifier) remain
unchanged.
🧹 Nitpick comments (3)
lib/services/mostro_service.dart (2)
151-153: Consider log level and content for production.Logging the full
decryptedEvent.contentmay expose sensitive trade details in log output. Consider using debug level (logger.d) for detailed payload logging, or truncating/redacting the content for info level.♻️ Suggested change
- logger.i( - 'Received DM, Event ID: ${decryptedEvent.id ?? event.id} with payload: ${decryptedEvent.content}', - ); + logger.d( + 'Received DM, Event ID: ${decryptedEvent.id ?? event.id} with payload: ${decryptedEvent.content}', + );
355-356: Consider debug level for outbound payload logging.Similar to the inbound DM logging, the outbound payload contains trade details. Using debug level would be more appropriate for detailed protocol logging.
♻️ Suggested change
- logger - .i('Sending DM, Event ID: ${event.id} with payload: ${order.toJson()}'); + logger + .d('Sending DM, Event ID: ${event.id} with payload: ${order.toJson()}');lib/services/nostr_service.dart (1)
129-148: Consider error level for publish failures.A failed event publish is typically a significant issue that could affect order processing. Using
logger.einstead oflogger.won line 139 would better reflect the severity.♻️ Suggested change
} catch (e) { - logger.w('Failed to publish event ${event.id}: $e'); + logger.e('Failed to publish event ${event.id}: $e');
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
docs/LOGGING_IMPLEMENTATION.mdlib/background/desktop_background_service.dartlib/background/mobile_background_service.dartlib/data/repositories/mostro_storage.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/order_notifier.dartlib/main.dartlib/services/deep_link_service.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
🧰 Additional context used
📓 Path-based instructions (6)
**/*.{dart,flutter}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{dart,flutter}: Runflutter analyzeafter any code change - Mandatory before commits to ensure zero linting issues
Runflutter testafter any code change - Mandatory before commits to ensure all unit tests pass
Files:
lib/main.dartlib/features/order/notfiers/add_order_notifier.dartlib/background/desktop_background_service.dartlib/data/repositories/mostro_storage.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/background/mobile_background_service.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
**/*.dart
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.dart: Use Riverpod for all state management - encapsulate business logic in Notifiers and access data only through repository classes
All code comments must be in English - use clear, concise English for variable names, function names, and comments
Always checkmountedbefore using BuildContext after async operations to prevent errors on disposed widgets
Useconstconstructors where possible for better performance and immutability
Remove unused imports and dependencies to maintain code cleanliness and reduce build size
**/*.dart: Application code should be organized underlib/, grouped by domain withlib/features/<feature>/structure, shared utilities inlib/shared/, dependency wiring inlib/core/, and services inlib/services/
Persistence, APIs, and background jobs should live inlib/data/andlib/background/; generated localization output must be inlib/generated/and must stay untouched
Applyflutter format .to enforce canonical Dart formatting (two-space indentation, trailing commas) before committing
Resolve every analyzer warning in Dart code
Name Riverpod providers using the<Feature>Provideror<Feature>Notifierconvention
Localize all user-facing strings via ARB files and access them withS.of(context)rather than hard-coded literals
Files:
lib/main.dartlib/features/order/notfiers/add_order_notifier.dartlib/background/desktop_background_service.dartlib/data/repositories/mostro_storage.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/background/mobile_background_service.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
lib/main.dart
📄 CodeRabbit inference engine (CLAUDE.md)
Configure timeago package locales in app initialization for proper relative time formatting (e.g., 'hace X horas' vs 'hours ago')
Files:
lib/main.dart
lib/data/repositories/**/*.dart
📄 CodeRabbit inference engine (CLAUDE.md)
Implement Repository pattern for all data access - all data operations must go through repository classes
Files:
lib/data/repositories/mostro_storage.dart
lib/services/**/*.dart
📄 CodeRabbit inference engine (CLAUDE.md)
Access NostrService for all Nostr protocol interactions - NostrService manages relay connections and messaging
Files:
lib/services/deep_link_service.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
lib/services/nostr_service.dart
📄 CodeRabbit inference engine (CLAUDE.md)
Manage all relay connections and Nostr messaging through NostrService - automatically reconnect when relay list updates
Files:
lib/services/nostr_service.dart
🧠 Learnings (39)
📓 Common learnings
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/background/background.dart:74-77
Timestamp: 2025-05-08T16:29:52.154Z
Learning: In the Mostro Mobile background service architecture, events aren't stored by the background process. Instead, the background service only checks if events exist in the eventStore and sends notifications for new ones, while the foreground process is responsible for storing and processing events. This is an intentional design decision to separate concerns.
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
📚 Learning: 2025-05-06T15:49:26.443Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Applied to files:
lib/main.dartlib/data/repositories/mostro_storage.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.081Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.081Z
Learning: Run `flutter test integration_test/` only for significant changes affecting core services and main user flows
Applied to files:
lib/main.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/subscriptions/subscription_manager.dart : Use SubscriptionManager with `fireImmediately: false` during SessionNotifier initialization to prevent premature execution
Applied to files:
lib/main.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/background/mobile_background_service.dartlib/services/mostro_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/**/notifiers/**/*.dart : Encapsulate business logic in Notifiers - Notifiers should expose state via providers and handle all complex state transitions
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/**/providers/**/*.dart : Use Notifier pattern instead of simple StateNotifier for complex state logic requiring business rule encapsulation
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/**/providers/**/*.dart : Organize Riverpod providers by feature in `features/{feature}/providers/` using Notifier pattern for complex state logic
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/orders/notifiers/add_order_notifier.dart : Start session timeout cleanup in `submitOrder()` method to prevent orphan sessions when Mostro doesn't respond within 10 seconds
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/auth/notifiers/abstract_mostro_notifier.dart : Start 10-second cleanup timer automatically when taking orders via `startSessionTimeoutCleanup()` to prevent orphan sessions
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/shared/**/*.dart : Follow existing feature patterns when adding new shared utilities - refer to order, chat, and auth features as implementation examples
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/order_notifier.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/auth/notifiers/abstract_mostro_notifier.dart : Use `startSessionTimeoutCleanupForRequestId()` for order creation timeout protection and cancel timer automatically when any Mostro response received
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/data/repositories/mostro_storage.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-10-21T21:47:03.451Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 327
File: lib/features/order/notfiers/abstract_mostro_notifier.dart:157-182
Timestamp: 2025-10-21T21:47:03.451Z
Learning: In MostroP2P/mobile, for Action.canceled handling in abstract_mostro_notifier.dart (Riverpod StateNotifier), do not add mounted checks after async sessionNotifier.deleteSession(orderId) as they break order state synchronization during app restart. The Action.canceled flow contains critical business logic that must complete fully; Riverpod handles provider disposal automatically. Mounted checks should only protect UI operations, not business logic in StateNotifiers.
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-10-14T21:12:06.887Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 327
File: lib/features/order/notfiers/abstract_mostro_notifier.dart:141-154
Timestamp: 2025-10-14T21:12:06.887Z
Learning: In the MostroP2P mobile codebase, the notification system uses a two-layer localization pattern: providers/notifiers (without BuildContext access) call `showCustomMessage()` with string keys (e.g., 'orderTimeoutMaker', 'orderCanceled'), and the UI layer's `NotificationListenerWidget` has a switch statement that maps these keys to localized strings using `S.of(context)`. This architectural pattern properly separates concerns while maintaining full localization support for all user-facing messages.
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/order/notfiers/order_notifier.dart
📚 Learning: 2025-06-26T15:03:23.529Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 127
File: lib/features/order/notfiers/abstract_mostro_notifier.dart:45-54
Timestamp: 2025-06-26T15:03:23.529Z
Learning: In AbstractMostroNotifier, state updates occur for all messages regardless of timestamp to hydrate the OrderNotifier from MostroStorage during sync, while handleEvent is only called for recent messages (within 60 seconds) to prevent re-triggering side effects like notifications and navigation for previously handled messages. This design prevents displaying stale notifications when the app is reopened or brought to the foreground.
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/core/mostro_fsm.dart : Use MostroFSM for managing order state transitions - all state changes must go through FSM state methods
Applied to files:
lib/features/order/notfiers/add_order_notifier.dartlib/services/deep_link_service.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/services/nostr_service.dart : Manage all relay connections and Nostr messaging through NostrService - automatically reconnect when relay list updates
Applied to files:
lib/background/desktop_background_service.dartlib/background/mobile_background_service.dartlib/services/deep_link_service.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/services/**/*.dart : Access NostrService for all Nostr protocol interactions - NostrService manages relay connections and messaging
Applied to files:
lib/background/desktop_background_service.dartlib/background/mobile_background_service.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/relays/**/*.dart : Use dual storage strategy: store Mostro/default relays in `settings.relays` and user relays in `settings.userRelays` with full JSON metadata via `toJson()`/`fromJson()`
Applied to files:
lib/data/repositories/mostro_storage.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/data/repositories/**/*.dart : Implement Repository pattern for all data access - all data operations must go through repository classes
Applied to files:
lib/data/repositories/mostro_storage.dart
📚 Learning: 2025-05-06T15:49:26.443Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, Riverpod code generation is used with `Riverpod` annotations. Providers like `eventStorageProvider` are generated in `.g.dart` files from annotated functions in the main provider files. These providers are accessible by importing the main provider file (e.g., `mostro_service_provider.dart`), not by importing a separate provider file.
Applied to files:
lib/data/repositories/mostro_storage.dartlib/services/deep_link_service.dartlib/services/mostro_service.dart
📚 Learning: 2025-07-20T23:33:17.689Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 215
File: lib/features/order/notfiers/order_notifier.dart:0-0
Timestamp: 2025-07-20T23:33:17.689Z
Learning: In AbstractMostroNotifier, the handleEvent method is synchronous and returns void, not Future<void>. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Applied to files:
lib/features/order/notfiers/abstract_mostro_notifier.dart
📚 Learning: 2025-05-06T15:49:55.079Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/services/mostro_service.dart:97-103
Timestamp: 2025-05-06T15:49:55.079Z
Learning: In the Mostro protocol, an order cannot be canceled unless it has a valid orderId, so null checks on orderId during cancel operations are unnecessary.
Applied to files:
lib/features/order/notfiers/abstract_mostro_notifier.dartlib/services/nostr_service.dart
📚 Learning: 2025-05-08T16:29:52.154Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/background/background.dart:74-77
Timestamp: 2025-05-08T16:29:52.154Z
Learning: In the Mostro Mobile background service architecture, events aren't stored by the background process. Instead, the background service only checks if events exist in the eventStore and sends notifications for new ones, while the foreground process is responsible for storing and processing events. This is an intentional design decision to separate concerns.
Applied to files:
lib/background/mobile_background_service.dartdocs/LOGGING_IMPLEMENTATION.md
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/core/app_routes.dart : Use GoRouter for all navigation configuration instead of Navigator API - maintain all routes in app_routes.dart
Applied to files:
lib/services/deep_link_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to **/*.dart : Use Riverpod for all state management - encapsulate business logic in Notifiers and access data only through repository classes
Applied to files:
lib/services/deep_link_service.dartlib/services/mostro_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:26.407Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-27T12:10:26.407Z
Learning: Applies to **/*.dart : Name Riverpod providers using the `<Feature>Provider` or `<Feature>Notifier` convention
Applied to files:
lib/services/deep_link_service.dartlib/features/order/notfiers/order_notifier.dartlib/services/mostro_service.dart
📚 Learning: 2025-05-08T16:31:29.582Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/notifications/notification_service.dart:54-59
Timestamp: 2025-05-08T16:31:29.582Z
Learning: In the Nostr protocol, event.id will never be null in events returned by relay subscriptions, so null safety checks for this property are unnecessary.
Applied to files:
lib/services/deep_link_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/core/models/relay_list_event.dart : Parse NIP-65 (kind 10002) events with robust handling of different timestamp formats and null-safe parsing for malformed events
Applied to files:
lib/services/deep_link_service.dartlib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to **/*.dart : Remove unused imports and dependencies to maintain code cleanliness and reduce build size
Applied to files:
lib/features/order/notfiers/order_notifier.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/settings/settings.dart : Use null-aware operators (`??`) in Settings `copyWith()` method to preserve existing values for selectedLanguage and defaultLightningAddress when not explicitly overridden
Applied to files:
lib/services/mostro_service.dart
📚 Learning: 2025-06-04T19:35:20.209Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 110
File: test/notifiers/take_order_notifier_test.dart:72-74
Timestamp: 2025-06-04T19:35:20.209Z
Learning: MostroService methods like takeBuyOrder() and takeSellOrder() return Future<void> and trigger side effects through other mechanisms rather than direct return values. When testing these methods, focus on verifying method calls and testing state changes through the provider system rather than mocking return values.
Applied to files:
lib/services/mostro_service.dart
📚 Learning: 2025-06-08T23:54:09.987Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 110
File: lib/features/trades/widgets/mostro_message_detail_widget.dart:134-141
Timestamp: 2025-06-08T23:54:09.987Z
Learning: In the OrderState refactor, public keys should be accessed via `tradeState.peer?.publicKey` from the OrderState instance rather than through `session?.peer?.publicKey`, as the OrderState encapsulates peer information directly.
Applied to files:
lib/services/mostro_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/relays/**/*.dart : Implement two-tier relay validation: primary Nostr protocol test (REQ/EVENT/EOSE) with WebSocket fallback for connectivity testing
Applied to files:
lib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/relays/**/*.dart : Track relay sources (user, mostro, default) using RelaySource enum for appropriate handling and storage strategy
Applied to files:
lib/services/nostr_service.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/relays/relays_notifier.dart : Use `removeRelayWithBlacklist()` for Mostro/default relays (adds to blacklist) and `removeRelay()` for permanent user relay deletion
Applied to files:
lib/services/nostr_service.dart
📚 Learning: 2025-05-06T15:46:08.942Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/services/nostr_service.dart:3-4
Timestamp: 2025-05-06T15:46:08.942Z
Learning: The file in dart_nostr library is named "ease.dart" (not "eose.dart" as might be expected), as confirmed by the project maintainer.
Applied to files:
lib/services/nostr_service.dart
📚 Learning: 2025-08-19T17:54:15.016Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 272
File: lib/features/relays/relays_notifier.dart:41-49
Timestamp: 2025-08-19T17:54:15.016Z
Learning: In the Mostro mobile app relay synchronization system, the hardcoded 'wss://relay.mostro.network' relay in RelaysNotifier._loadRelays() is intentional for bootstrapping. Config.nostrRelays only contains this single active relay anyway (other entries are commented-out dev relays), so hardcoding is functionally equivalent and more explicit about the bootstrap requirement for fetching kind 10002 relay list events.
Applied to files:
lib/services/nostr_service.dart
📚 Learning: 2026-01-09T22:09:06.887Z
Learnt from: BraCR10
Repo: MostroP2P/mobile PR: 403
File: lib/features/settings/settings_notifier.dart:153-156
Timestamp: 2026-01-09T22:09:06.887Z
Learning: In lib/features/settings/settings_notifier.dart, the updateLoggingEnabled method intentionally does NOT call _saveToPrefs() because the logging toggle should not persist across app restarts. The isLoggingEnabled field is deliberately excluded from Settings.toJson() and always returns false in fromJson() for security and performance reasons, requiring users to explicitly enable logging each session.
Applied to files:
lib/services/nostr_service.dart
📚 Learning: 2025-08-21T14:45:43.974Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 272
File: lib/features/relays/widgets/relay_selector.dart:13-15
Timestamp: 2025-08-21T14:45:43.974Z
Learning: In the Mostro mobile app's RelaySelector widget (lib/features/relays/widgets/relay_selector.dart), watching relaysProvider.notifier correctly triggers rebuilds because the relaysProvider itself depends on settingsProvider (line 8 in relays_provider.dart). When blacklist changes via toggleMostroRelayBlacklist(), the settingsProvider updates, causing relaysProvider to rebuild, which then notifies widgets watching the notifier. The UI correctly reflects active/inactive states in real-time through this dependency chain.
Applied to files:
lib/services/nostr_service.dart
🪛 LanguageTool
docs/LOGGING_IMPLEMENTATION.md
[grammar] ~30-~30: Ensure spelling is correct
Context: ...tro_storage - AbstractMostroNotifier + subclases (AddOrderNotifier, OrderNotifier) ### ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (24)
lib/data/repositories/mostro_storage.dart (1)
1-8: LGTM! Clean migration to centralized logger.The logging migration correctly removes the private
_loggerfield and imports the sharedlogger_service. All subsequent logging calls properly use the globalloggersingleton with appropriate log levels (logger.ifor info,logger.efor errors witherrorandstackTraceparameters).lib/services/deep_link_service.dart (2)
7-7: LGTM! Logging migration follows established patterns.The migration correctly replaces the local
Loggerinstance with the centralizedloggersingleton. The service appropriately uses different log levels (logger.i,logger.e,logger.w) throughout the deep link processing flow.Also applies to: 25-25
111-116: Good defensive coding withcontext.mountedcheck.The mounted check before using
BuildContextafter the async_fetchOrderInfoByIdcall correctly prevents errors on disposed widgets, as per coding guidelines.lib/background/mobile_background_service.dart (1)
7-7: LGTM! Isolate logging properly wired.The aliased import and passing of
isolateLogSenderPortenables log forwarding from the background isolate to the main isolate's memory buffer. This correctly implements the isolate logging pattern documented in Phase 4.Also applies to: 46-50
docs/LOGGING_IMPLEMENTATION.md (1)
25-35: Documentation accurately reflects Phase 3 & 4 completion.The updates correctly document the migration of core services (
mostro_storage,AbstractMostroNotifierand its subclasses) and the isolate logging integration for both mobile and desktop background services. Version and status metadata are appropriately updated.Also applies to: 209-211
lib/background/desktop_background_service.dart (2)
22-36: Isolate logger correctly configured with dedicated output.The isolate properly creates its own
Loggerinstance withIsolateLogOutputto forward logs to the main isolate viaSendPort. This follows the documented pattern inLOGGING_IMPLEMENTATION.mdfor background isolate integration.
26-26:IsolateLogOutputcorrectly handles nullSendPort.The implementation (lib/services/logger_service.dart:283-311) always prints logs to console and conditionally sends to the
SendPortonly when it's not null (line 295:if (sendPort != null)). Whenargs.length <= 2andloggerSendPortis null, logs will still be output to console—no runtime errors possible.lib/services/mostro_service.dart (3)
7-7: Import migration to centralized logger service.The import change aligns with the project-wide logging standardization.
30-41: Logging in subscription and dispose is well-structured.Error logging correctly includes both
errorandstackTraceparameters for proper debugging. The dispose log provides useful lifecycle visibility.
45-95: Defensive restore payload detection is well-implemented.The
_isRestorePayloadmethod includes thorough type validation at each step, preventing runtime type errors. The comments clearly explain the purpose of each check.lib/services/nostr_service.dart (5)
6-6: Import migration to centralized logger service.
29-73: Comprehensive logging in initialization flow.Excellent use of log levels:
- Debug for protocol-level details (OK, EOSE, Count responses)
- Info for operational events (Notice, connection success)
- Warning for recoverable issues (connection errors)
- Error for failures
This provides good observability without overwhelming logs.
75-111: Robust relay update with fallback and logging.The update logic properly handles failures by attempting to restore previous configuration. Logging at each step provides a clear audit trail for debugging relay connectivity issues.
264-320: Thorough logging in event fetch operations.The
fetchEventByIdmethod has comprehensive logging covering the success path, validation failures, and error handling. Log levels are appropriate for each scenario.
410-457: Good error recovery in relay-specific fetch.The
_fetchFromSpecificRelaysmethod properly restores original relay settings even on error, with logging at each step for debugging.lib/features/order/notfiers/add_order_notifier.dart (2)
9-9: Import added for centralized logger service.The import enables usage of the shared
loggerinstance throughout the notifier, consistent with other migrated files.
39-43: Logger usage in subscription handler is appropriate.The info log for received actions provides useful visibility into the order creation flow.
lib/features/order/notfiers/order_notifier.dart (4)
9-9: Import added for centralized logger service.Consistent with the project-wide logging migration.
24-30: Event handling logging provides good observability.Logging received events with action and order ID helps trace the order lifecycle.
32-72: Sync method has comprehensive logging.The sync method appropriately logs:
- Warning when no messages found (helps identify data issues)
- Info on successful sync with status
- Error with full stack trace on failures
This provides good debugging capability for order state synchronization.
157-192: Automatic expiration handling is well-logged.The public events subscription logs automatic order expiration clearly, which is valuable for understanding order lifecycle transitions. Error handling includes full stack traces for debugging.
lib/main.dart (1)
19-27: Logger service integration is correctly implemented.The
initIsolateLogReceiver()function is synchronous (returnsvoid), so the call at line 26 is appropriately withoutawait. Placement early inmain()ensures background isolate logs are captured from startup. Timeago localization is properly configured at line 42 as required by guidelines.lib/features/order/notfiers/abstract_mostro_notifier.dart (2)
14-14: LGTM!Import correctly migrated to the centralized logger service, aligning with the Phase 3 logging migration objectives.
499-575: LGTM!The static methods correctly use the global
loggersingleton from the centralized logger service. The logging pattern is consistent throughout:
logger.i()for informational messages about timer lifecyclelogger.e()with theerror:named parameter for structured error captureThis is the appropriate approach for static methods where instance-level dependencies aren't available.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
lib/services/logger_service.dart (3)
109-113: Potential runtime exception if timestamp is shorter than 19 characters.The
format()method usessubstring(0, 19)without checking string length. WhileDateTime.toString()typically produces strings longer than 19 characters, this is an implicit assumption.🐛 Safer substring handling
String format() { - final time = timestamp.toString().substring(0, 19); + final timeStr = timestamp.toString(); + final time = timeStr.length >= 19 ? timeStr.substring(0, 19) : timeStr; final levelStr = level.toString().split('.').last.toUpperCase(); return '[$levelStr]($service:$line) $time - $message'; }
186-187: Same substring safety concern in SimplePrinter.Line 187 uses
substring(0, 19)on the timestamp string without length validation, same issue as inLogEntry.format().🐛 Safer substring handling
List<String> log(LogEvent event) { final level = _formatLevel(event.level); final message = event.message.toString(); - final timestamp = event.time.toString().substring(0, 19); + final timeStr = event.time.toString(); + final timestamp = timeStr.length >= 19 ? timeStr.substring(0, 19) : timeStr;
155-164: Fix inverted condition in buffer deletion logic — the inner check is logically impossible.The condition
_buffer.length < Config.logBatchDeleteSizeinside a block where_buffer.length > Config.logMaxEntriescan never be true given the constants (logMaxEntries = 1000, logBatchDeleteSize = 100). This meansdeleteCountwill always be 100, and the first branch is dead code.The intent appears to be: delete only the overflow amount if it's small, otherwise delete a batch. The correct condition should check if the overflow exceeds the batch size:
(_buffer.length - Config.logMaxEntries) < Config.logBatchDeleteSize.lib/background/background.dart (1)
66-92: Store the StreamSubscription returned by.listen()to enable proper cleanup.The
subscription.listen()call on line 82 creates aStreamSubscriptionthat isn't stored. Only theStreamobject is kept inactiveSubscriptions, while the listener subscription itself is lost. Whencancel-subscriptionfires,nostrService.unsubscribe(id)is called, but there's no local handle to explicitly cancel the listener. This is inconsistent with the pattern used elsewhere in the codebase (e.g.,SubscriptionManager,OpenOrdersRepository,DisputeChatNotifier) whereStreamSubscriptionobjects are explicitly stored and managed.Store the
StreamSubscriptioninactiveSubscriptionsso it can be properly cancelled when the subscription is removed. Update line 82-91:final streamSubscription = subscription.listen((event) async { try { if (await eventStore.hasItem(event.id!)) { return; } await notification_service.retryNotification(event); } catch (e) { logger?.e('Error processing event', error: e); } }); activeSubscriptions[request.subscriptionId!] = { 'filters': filters, 'subscription': subscription, 'streamSubscription': streamSubscription, };Then update the cancel handler (line 98-100) to also cancel the listener:
if (id != null && activeSubscriptions.containsKey(id)) { final sub = activeSubscriptions[id]; (sub?['streamSubscription'] as StreamSubscription?)?.cancel(); activeSubscriptions.remove(id); nostrService.unsubscribe(id); }
🧹 Nitpick comments (3)
lib/services/logger_service.dart (1)
33-50: Comprehensive log sanitization, but consider pre-compiling regex patterns.The
cleanMessagefunction properly sanitizes logs by:
- Removing ANSI escape codes
- Stripping box-drawing characters and emojis
- Redacting sensitive data (private keys, mnemonics)
However, these regex patterns are recompiled on every call. For a logging service that may process many messages, pre-compiling these patterns would improve performance.
♻️ Consider pre-compiling regex patterns
// At module level, before cleanMessage function: final _ansiEscapeRegex = RegExp(r'\x1B\[[0-9;]*[a-zA-Z]'); final _digitBracketRegex = RegExp(r'\[\d+m'); final _ansi256Regex = RegExp(r'\[38;5;\d+m'); final _ansi39Regex = RegExp(r'\[39m'); final _ansi2Regex = RegExp(r'\[2m'); final _ansi22Regex = RegExp(r'\[22m'); final _boxCharsRegex = RegExp(r'[┌┐└┘├┤─│┬┴┼╭╮╰╯╔╗╚╝╠╣═║╦╩╬━┃┄├]'); final _emojiRegex = RegExp(r'[\u{1F300}-\u{1F9FF}]', unicode: true); final _nsecRegex = RegExp(r'nsec[0-9a-z]+'); final _privateKeyRegex = RegExp(r'"privateKey"\s*:\s*"[^"]*"'); final _mnemonicRegex = RegExp(r'"mnemonic"\s*:\s*"[^"]*"'); final _nonAlnumRegex = RegExp(r'[^A-Za-z0-9\s.:,!?\-_/\[\]]'); final _whitespaceRegex = RegExp(r'\s+'); String cleanMessage(String message) { return message .replaceAll(_ansiEscapeRegex, '') // ... use pre-compiled patterns .trim(); }lib/background/background.dart (2)
20-21: Logger initialization placement may cause missed logs during startup.The
loggeris only initialized inside the'start'listener after receiving theloggerSendPort. Any logs emitted before the'start'event is received (e.g., duringNostrServiceinstantiation on line 24 or database opening on line 25) will not be captured.This may be intentional given the isolate architecture constraints, but consider whether early startup diagnostics are needed.
Additionally, note that the logger is set to
Level.debugunconditionally on line 43. In production builds, this might generate more verbose logs than desired through the isolate channel. Consider aligning withConfig.isDebug:♻️ Consider conditional log level
logger = Logger( printer: logger_service.SimplePrinter(), output: logger_service.IsolateLogOutput(loggerSendPort), - level: Level.debug, + level: Config.isDebug ? Level.debug : Level.warning, );This would require importing
Configif not already available.Also applies to: 38-44
89-89: Null-safe logging is correct but errors may be silently lost.Using
logger?.e(...)safely handles the case where logger hasn't been initialized. However, if an error occurs before the'start'event (whenloggeris still null), the error will be silently swallowed.Consider adding a fallback for critical errors:
♻️ Fallback for pre-initialization errors
} catch (e) { - logger?.e('Error processing event', error: e); + if (logger != null) { + logger!.e('Error processing event', error: e); + } else { + // ignore: avoid_print + print('Error processing event before logger init: $e'); + } }
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
lib/background/background.dartlib/services/logger_service.dart
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{dart,flutter}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{dart,flutter}: Runflutter analyzeafter any code change - Mandatory before commits to ensure zero linting issues
Runflutter testafter any code change - Mandatory before commits to ensure all unit tests pass
Files:
lib/services/logger_service.dartlib/background/background.dart
**/*.dart
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.dart: Use Riverpod for all state management - encapsulate business logic in Notifiers and access data only through repository classes
All code comments must be in English - use clear, concise English for variable names, function names, and comments
Always checkmountedbefore using BuildContext after async operations to prevent errors on disposed widgets
Useconstconstructors where possible for better performance and immutability
Remove unused imports and dependencies to maintain code cleanliness and reduce build size
**/*.dart: Application code should be organized underlib/, grouped by domain withlib/features/<feature>/structure, shared utilities inlib/shared/, dependency wiring inlib/core/, and services inlib/services/
Persistence, APIs, and background jobs should live inlib/data/andlib/background/; generated localization output must be inlib/generated/and must stay untouched
Applyflutter format .to enforce canonical Dart formatting (two-space indentation, trailing commas) before committing
Resolve every analyzer warning in Dart code
Name Riverpod providers using the<Feature>Provideror<Feature>Notifierconvention
Localize all user-facing strings via ARB files and access them withS.of(context)rather than hard-coded literals
Files:
lib/services/logger_service.dartlib/background/background.dart
lib/services/**/*.dart
📄 CodeRabbit inference engine (CLAUDE.md)
Access NostrService for all Nostr protocol interactions - NostrService manages relay connections and messaging
Files:
lib/services/logger_service.dart
🧠 Learnings (13)
📚 Learning: 2025-11-27T12:10:26.407Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: AGENTS.md:0-0
Timestamp: 2025-11-27T12:10:26.407Z
Learning: Applies to **/*.dart : Persistence, APIs, and background jobs should live in `lib/data/` and `lib/background/`; generated localization output must be in `lib/generated/` and must stay untouched
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/**/notifiers/**/*.dart : Encapsulate business logic in Notifiers - Notifiers should expose state via providers and handle all complex state transitions
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to **/*.dart : Always check `mounted` before using BuildContext after async operations to prevent errors on disposed widgets
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.081Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.081Z
Learning: Run `flutter test integration_test/` only for significant changes affecting core services and main user flows
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/services/nostr_service.dart : Manage all relay connections and Nostr messaging through NostrService - automatically reconnect when relay list updates
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/services/**/*.dart : Access NostrService for all Nostr protocol interactions - NostrService manages relay connections and messaging
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/subscriptions/subscription_manager.dart : Use SubscriptionManager with `fireImmediately: false` during SessionNotifier initialization to prevent premature execution
Applied to files:
lib/background/background.dart
📚 Learning: 2025-10-14T21:12:06.887Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 327
File: lib/features/order/notfiers/abstract_mostro_notifier.dart:141-154
Timestamp: 2025-10-14T21:12:06.887Z
Learning: In the MostroP2P mobile codebase, the notification system uses a two-layer localization pattern: providers/notifiers (without BuildContext access) call `showCustomMessage()` with string keys (e.g., 'orderTimeoutMaker', 'orderCanceled'), and the UI layer's `NotificationListenerWidget` has a switch statement that maps these keys to localized strings using `S.of(context)`. This architectural pattern properly separates concerns while maintaining full localization support for all user-facing messages.
Applied to files:
lib/background/background.dart
📚 Learning: 2025-05-06T15:49:26.443Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/services/mostro_service.dart:70-76
Timestamp: 2025-05-06T15:49:26.443Z
Learning: In the Mostro Mobile codebase, `eventStorageProvider` is exported from `package:mostro_mobile/shared/providers/mostro_service_provider.dart` and not from a separate `event_storage_provider.dart` file.
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/**/providers/**/*.dart : Use Notifier pattern instead of simple StateNotifier for complex state logic requiring business rule encapsulation
Applied to files:
lib/background/background.dart
📚 Learning: 2025-05-08T16:29:52.154Z
Learnt from: chebizarro
Repo: MostroP2P/mobile PR: 74
File: lib/background/background.dart:74-77
Timestamp: 2025-05-08T16:29:52.154Z
Learning: In the Mostro Mobile background service architecture, events aren't stored by the background process. Instead, the background service only checks if events exist in the eventStore and sends notifications for new ones, while the foreground process is responsible for storing and processing events. This is an intentional design decision to separate concerns.
Applied to files:
lib/background/background.dart
📚 Learning: 2025-11-27T12:10:12.082Z
Learnt from: CR
Repo: MostroP2P/mobile PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-27T12:10:12.082Z
Learning: Applies to lib/features/settings/settings.dart : Use null-aware operators (`??`) in Settings `copyWith()` method to preserve existing values for selectedLanguage and defaultLightningAddress when not explicitly overridden
Applied to files:
lib/background/background.dart
📚 Learning: 2025-07-20T23:33:17.689Z
Learnt from: Catrya
Repo: MostroP2P/mobile PR: 215
File: lib/features/order/notfiers/order_notifier.dart:0-0
Timestamp: 2025-07-20T23:33:17.689Z
Learning: In AbstractMostroNotifier, the handleEvent method is synchronous and returns void, not Future<void>. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Applied to files:
lib/background/background.dart
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (4)
lib/services/logger_service.dart (3)
11-29: LGTM! Proper isolate receiver initialization with idempotency guard.The initialization correctly prevents duplicate receivers with the early return check on line 12. The listener handles message processing with appropriate error catching. One minor observation: the error handling uses
52-81: Timestamp parsing is robust with fallback handling.The function correctly handles null and invalid timestamps by falling back to
DateTime.now(). The message sanitization viacleanMessageensures sensitive data is redacted before storage.
289-312: Changed code segment: Debug-only console printing is correctly gated.The changes on lines 290-295 ensure console output only occurs in debug mode via
Config.isDebug, which aligns with the PR objective to "print background isolate logs to console only in debug mode." The log message is properly sanitized before being sent via theSendPort.The implementation correctly:
- Prints to console only in debug builds
- Sends sanitized log data through the isolate channel regardless of debug mode (when
sendPortis available)lib/background/background.dart (1)
2-2: Imports correctly added for isolate and logger service integration.The
dart:isolateimport is needed forSendPort, and the aliased import oflogger_serviceprovides access toSimplePrinterandIsolateLogOutput.Also applies to: 12-12
AndreaDiazCorreia
left a comment
AndreaDiazCorreia
left a comment
There was a problem hiding this comment.
I was testing it, and it seems to me that everything works fine. tACK
Hola @Catrya, respecto a este Nitpick revisé y lo que advierte es que se podría perder algún log antes de la inicialización. Sin embargo, los servicios instanciados antes (NostrService, EventStorage) tienen constructores sin logging, y todas las operaciones reales ocurren después de que el logger está listo. Mover la inicialización de estos servicios al listener 'start' complicaría el código porque requeriría usar variables late, agregar verificaciones de null y aumentaría el riesgo de errores en tiempo de ejecución. Además, prefiero mantener el nivel debug para mostrar los logs completos en la UI. |
3 participants
Phase 3 & 4: Core Services Migration & Isolate Logging
This PR migrates 5 core services to use the logging system and enables background isolate logging.
What's Included
Phase 3 - Service Migrations (5 files):
lib/services/nostr_service.dart- Migrated to logger singleton (45+ log calls)lib/services/mostro_service.dart- Migrated to logger singleton (~12 log calls)lib/services/deep_link_service.dart- Migrated to logger singletonlib/data/repositories/mostro_storage.dart- Migrated to logger singletonlib/features/order/notifiers/abstract_mostro_notifier.dart+ subclasses - Migrated to logger singletonPhase 4 - Isolate Logging:
lib/main.dart- AddedinitIsolateLogReceiver()to capture background service logsbackground\mobile_background_service.dartdesktop_background_service.dartExpected Logs
With this PR, the logs screen will now display:
Testing
Navigate to: Settings → Dev Tools → Logs Report
See
docs/LOGGING_IMPLEMENTATION.mdfor complete details.Summary by CodeRabbit
New Features
Chores
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.