feat: implement timeout detection and reversal system for orders in waiting-payment and waiting-buyer-invoice #243
Conversation
- Add real-time timeout detection for orders in waiting-buyer-invoice and waiting-payment states - Implement differentiated handling: makers preserve sessions and revert to pending, takers clean up sessions completely - Add race condition protection with _isProcessingTimeout flag to prevent concurrent rocessing - Integrate synthetic message enrichment for complete order data persistence across app restarts - Add operation timeouts (8s detection, 5s storage) to prevent application hangs - Implement maker/taker role determination based on session role and order type matching - Add contextual timeout notifications in 3 languages with appropriate user messaging System automatically monitors public events (38383) and compares timestamps with latest gift wrap messages to detect when orders timeout from waiting states, ensuring UI consistency with mostrod state without requiring app restarts.
|
""" WalkthroughThis change set introduces comprehensive timeout detection and handling for orders, including new timeout constants, a new enum action ( Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant OrderNotifier
participant PublicEventStream
participant NotificationNotifier
participant UI
loop Real-time
PublicEventStream->>OrderNotifier: New public order event
OrderNotifier->>OrderNotifier: _checkTimeoutAndCleanup()
alt Timeout detected
OrderNotifier->>NotificationNotifier: showCustomMessage(orderTimeoutTaker/Maker)
NotificationNotifier->>UI: Display localized timeout notification
OrderNotifier->>OrderNotifier: Update state (timeoutReversal)
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Suggested reviewers
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (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)
✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
lib/features/order/notfiers/order_notifier.dart (2)
40-94: Consider adjusting log level for empty messagesThe warning log for empty messages might be too verbose for new orders where no messages exist yet. Otherwise, the implementation with timeout detection and race condition prevention is well done.
if (messages.isEmpty) { - logger.w('No messages found for order $orderId'); + logger.d('No messages found for order $orderId'); return; }
157-269: Consider refactoring this method for better maintainabilityWhile the implementation is correct, this method is quite long (110+ lines) and handles multiple responsibilities. Consider extracting the maker and taker handling logic into separate methods.
Example refactoring approach:
Future<bool> _checkTimeoutAndCleanup(OrderState currentState, MostroMessage? latestGiftWrap) async { // Early returns and validation... if (publicTimestamp != null && publicTimestamp.isAfter(giftWrapTimestamp)) { final currentSession = ref.read(sessionProvider(orderId)); if (currentSession == null) return false; final isCreatedByUser = _isCreatedByUser(currentSession, publicEvent); return isCreatedByUser ? await _handleMakerTimeout(currentState, publicEvent, publicTimestamp) : await _handleTakerTimeout(); } return false; } Future<bool> _handleMakerTimeout(OrderState currentState, NostrEvent publicEvent, DateTime publicTimestamp) async { // Maker-specific logic... return false; // Session preserved } Future<bool> _handleTakerTimeout() async { // Taker-specific logic... return true; // Session cleaned up }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
lib/core/config.dart(2 hunks)lib/data/models/enums/action.dart(1 hunks)lib/data/models/mostro_message.dart(2 hunks)lib/features/order/models/order_state.dart(7 hunks)lib/features/order/notfiers/abstract_mostro_notifier.dart(1 hunks)lib/features/order/notfiers/order_notifier.dart(2 hunks)lib/features/trades/widgets/mostro_message_detail_widget.dart(2 hunks)lib/l10n/intl_en.arb(1 hunks)lib/l10n/intl_es.arb(1 hunks)lib/l10n/intl_it.arb(1 hunks)lib/shared/notifiers/notification_notifier.dart(2 hunks)lib/shared/widgets/notification_listener_widget.dart(2 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
lib/**/*.dart
📄 CodeRabbit Inference Engine (CLAUDE.md)
lib/**/*.dart: UseS.of(context).yourKeyfor all user-facing strings
Always checkmountedbefore using context after async operations
Files:
lib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/trades/widgets/mostro_message_detail_widget.dartlib/data/models/enums/action.dartlib/shared/notifiers/notification_notifier.dartlib/features/order/models/order_state.dartlib/shared/widgets/notification_listener_widget.dartlib/core/config.dartlib/data/models/mostro_message.dartlib/features/order/notfiers/order_notifier.dart
**/*.dart
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.dart: Remove unused imports and dependencies
Useconstconstructors where possible
Files:
lib/features/order/notfiers/abstract_mostro_notifier.dartlib/features/trades/widgets/mostro_message_detail_widget.dartlib/data/models/enums/action.dartlib/shared/notifiers/notification_notifier.dartlib/features/order/models/order_state.dartlib/shared/widgets/notification_listener_widget.dartlib/core/config.dartlib/data/models/mostro_message.dartlib/features/order/notfiers/order_notifier.dart
lib/l10n/intl_{en,es,it}.arb
📄 CodeRabbit Inference Engine (CLAUDE.md)
Add new localization keys to all three ARB files (
intl_en.arb,intl_es.arb,intl_it.arb)
Files:
lib/l10n/intl_en.arblib/l10n/intl_it.arblib/l10n/intl_es.arb
lib/l10n/*.arb
📄 CodeRabbit Inference Engine (CLAUDE.md)
Use proper ARB metadata for parameterized strings
Files:
lib/l10n/intl_en.arblib/l10n/intl_it.arblib/l10n/intl_es.arb
lib/l10n/**
📄 CodeRabbit Inference Engine (CLAUDE.md)
Internationalization files are located in
lib/l10n/
Files:
lib/l10n/intl_en.arblib/l10n/intl_it.arblib/l10n/intl_es.arb
🧠 Learnings (13)
📓 Common learnings
Learnt from: chebizarro
PR: MostroP2P/mobile#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.
lib/features/order/notfiers/abstract_mostro_notifier.dart (8)
Learnt from: chebizarro
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.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/features//notifiers/**/.dart : Notifiers for complex state logic are placed in features/{feature}/notifiers/
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/data/models/nostr_event.dart : Custom timeAgoWithLocale() method is implemented in the NostrEvent extension
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to test/mocks.mocks.dart : DO NOT modify test/mocks.mocks.dart - it already has file-level ignores
lib/features/trades/widgets/mostro_message_detail_widget.dart (7)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: chebizarro
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.
Learnt from: chebizarro
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 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.
Learnt from: chebizarro
PR: #74
File: lib/shared/providers/app_init_provider.dart:78-95
Timestamp: 2025-05-06T16:08:19.352Z
Learning: In the Mostro Mobile codebase, MostroMessage objects have an 'action' member that can be directly accessed (e.g., mostroMessage.action).
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
lib/data/models/enums/action.dart (1)
Learnt from: chebizarro
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 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.
lib/shared/notifiers/notification_notifier.dart (2)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/features//notifiers/**/.dart : Notifiers for complex state logic are placed in features/{feature}/notifiers/
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Encapsulate business logic in Notifiers
lib/features/order/models/order_state.dart (4)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: chebizarro
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.
Learnt from: chebizarro
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.
Learnt from: chebizarro
PR: #74
File: lib/shared/providers/app_init_provider.dart:78-95
Timestamp: 2025-05-06T16:08:19.352Z
Learning: In the Mostro Mobile codebase, MostroMessage objects have an 'action' member that can be directly accessed (e.g., mostroMessage.action).
lib/l10n/intl_en.arb (2)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/l10n/intl_{en,es,it}.arb : Add new localization keys to all three ARB files (intl_en.arb, intl_es.arb, intl_it.arb)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/l10n/*.arb : Use proper ARB metadata for parameterized strings
lib/shared/widgets/notification_listener_widget.dart (17)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/features//notifiers/**/.dart : Notifiers for complex state logic are placed in features/{feature}/notifiers/
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/data/models/nostr_event.dart : Custom timeAgoWithLocale() method is implemented in the NostrEvent extension
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/main.dart : Locales for the timeago package are configured in main.dart with timeago.setLocaleMessages()
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/app_routes.dart : GoRouter navigation is configured in core/app_routes.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Use Riverpod for all state management
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/data/models.dart : Models should be exported through data/models.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/shared/providers/mostro_database_provider.dart : Database initialization is in shared/providers/mostro_database_provider.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to test/mocks.mocks.dart : DO NOT modify test/mocks.mocks.dart - it already has file-level ignores
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/services/nostr_service.dart : Nostr protocol interactions go through services/nostr_service.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Pass BuildContext to methods that need localization
lib/core/config.dart (5)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/main.dart : Locales for the timeago package are configured in main.dart with timeago.setLocaleMessages()
Learnt from: chebizarro
PR: #127
File: lib/data/models/cant_do.dart:10-27
Timestamp: 2025-07-08T05:40:47.527Z
Learning: In the CantDo model parsing in lib/data/models/cant_do.dart, the inconsistent key naming between 'cant_do' (top-level) and 'cant-do' (nested) is required by the protocol specification and should not be changed as it would break message parsing compatibility.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/services/nostr_service.dart : Nostr protocol interactions go through services/nostr_service.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/shared/providers/mostro_database_provider.dart : Database initialization is in shared/providers/mostro_database_provider.dart
Learnt from: chebizarro
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.
lib/l10n/intl_it.arb (1)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/l10n/intl_{en,es,it}.arb : Add new localization keys to all three ARB files (intl_en.arb, intl_es.arb, intl_it.arb)
lib/l10n/intl_es.arb (2)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/l10n/intl_{en,es,it}.arb : Add new localization keys to all three ARB files (intl_en.arb, intl_es.arb, intl_it.arb)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/l10n/*.arb : Use proper ARB metadata for parameterized strings
lib/data/models/mostro_message.dart (13)
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: chebizarro
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 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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/data/models/nostr_event.dart : Custom timeAgoWithLocale() method is implemented in the NostrEvent extension
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/services/nostr_service.dart : Nostr protocol interactions go through services/nostr_service.dart
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/data/models.dart : Models should be exported through data/models.dart
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to test/mocks.mocks.dart : DO NOT modify test/mocks.mocks.dart - it already has file-level ignores
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/features//notifiers/**/.dart : Notifiers for complex state logic are placed in features/{feature}/notifiers/
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/shared/providers/mostro_database_provider.dart : Database initialization is in shared/providers/mostro_database_provider.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/data/repositories/**/*.dart : All data access should go through repository classes in data/repositories/
Learnt from: chebizarro
PR: #74
File: lib/features/trades/models/trade_state.dart:1-15
Timestamp: 2025-05-08T16:06:33.665Z
Learning: In the context of the Mostro Mobile app, the TradeState class is specifically constructed using the tradeStateProvider. While some fields are nullable (lastAction and orderPayload), they are still marked as required parameters to ensure they are explicitly considered during state construction.
lib/features/order/notfiers/order_notifier.dart (12)
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/features//notifiers/**/.dart : Notifiers for complex state logic are placed in features/{feature}/notifiers/
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Encapsulate business logic in Notifiers
Learnt from: chebizarro
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 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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/services/nostr_service.dart : Nostr protocol interactions go through services/nostr_service.dart
Learnt from: chebizarro
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.
Learnt from: chebizarro
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.
Learnt from: chebizarro
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.
⏰ 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 (26)
lib/core/config.dart (1)
41-43: LGTM! Well-defined timeout constants for critical operations.The new timeout constants are appropriately configured for the timeout detection system:
timeoutDetectionTimeout(8s) provides adequate detection windowmessageStorageTimeout(5s) prevents hanging during storage operationsThe comments clearly indicate these are for critical operations, which aligns with the timeout detection feature being implemented.
lib/features/order/notfiers/abstract_mostro_notifier.dart (1)
221-223: LGTM! Correct handling for timeoutReversal action.The explicit no-op case with a clear comment explaining that handling is done manually in OrderNotifier is the right approach. This follows the established pattern in the codebase where some actions require specialized handling rather than the standard notification flow.
lib/data/models/enums/action.dart (1)
42-42: LGTM! Proper enum extension following established conventions.The new
timeoutReversalenum member correctly follows the kebab-case naming convention used throughout the enum and integrates seamlessly with the existingfromStringmethod via the_valueMap.lib/features/trades/widgets/mostro_message_detail_widget.dart (2)
43-45: LGTM! Appropriate conditional display logic for timeout reversal.The conditional logic correctly displays only the order status for
timeoutReversalactions, avoiding redundant text display. This makes sense since the action text already provides the necessary context about the timeout.
196-197: LGTM! Proper localization usage for timeout reversal message.The case correctly returns the localized string
orderTimeoutMakerexplaining that the counterpart didn't respond in time and the order will be republished. The implementation follows the established pattern and usesS.of(context)!as required by the coding guidelines.lib/l10n/intl_en.arb (1)
659-661: Localization keys present in all ARB filesVerified that both
orderTimeoutTakerandorderTimeoutMakerappear in:
- lib/l10n/intl_en.arb
- lib/l10n/intl_es.arb
- lib/l10n/intl_it.arb
No further changes needed.
lib/l10n/intl_es.arb (1)
689-692: LGTM! Timeout localization keys properly added.The Spanish translations for the timeout notification messages are clear and contextually appropriate. The messages correctly inform users when either they or their counterpart failed to respond within the timeout window, and that the order will be republished.
lib/l10n/intl_it.arb (1)
697-700: LGTM! Italian timeout localization keys properly added.The Italian translations for the timeout notification messages are accurate and contextually appropriate. The messages clearly communicate that either the user or their counterpart didn't respond in time and that the order will be republished.
lib/features/order/models/order_state.dart (7)
85-85: LGTM! Simplified logging output.Removing emojis from logging makes the debug output cleaner and more professional.
96-98: LGTM! Clear status mapping debug information.The simplified debug logging provides clear information about action to status mapping without unnecessary visual clutter.
103-103: LGTM! Consistent logging style.The PaymentRequest logging is now consistent with the simplified logging approach.
140-143: LGTM! Enhanced state logging.The improved logging provides better visibility into the new state creation and PaymentRequest preservation, which is valuable for debugging timeout scenarios.
229-232: LGTM! Proper timeout reversal handling.The
timeoutReversalaction correctly returns the payload status (which should bependingfor timeout reversals) or defaults toStatus.pending. This aligns with the expected behavior of reverting orders back to pending state after a timeout.
252-255: LGTM! Timeout reversal action added to seller pending state.The
timeoutReversalaction is properly added to the seller's pending state withcancelas the available action, which is appropriate since users should be able to cancel after a timeout reversal.
373-376: LGTM! Timeout reversal action added to buyer pending state.The
timeoutReversalaction is consistently added to the buyer's pending state withcancelas the available action, maintaining symmetry with the seller state.lib/shared/notifiers/notification_notifier.dart (3)
11-11: LGTM! Appropriate nullable field addition.The
customMessagefield is correctly nullable, allowing for both custom and standard notification messages.
18-20: LGTM! Constructor properly updated.The constructor correctly includes the new
customMessageparameter while maintaining backward compatibility.
31-35: LGTM! Well-designed custom message method.The
showCustomMessagemethod follows the same pattern as existing methods, correctly setting the state with an informational notification containing the custom message. This enables timeout notifications to display localized custom messages.lib/data/models/mostro_message.dart (2)
8-11: LGTM! Necessary imports for timeout reversal functionality.The new imports are required for the timeout reversal factory constructor implementation and are properly organized.
32-81: Well-implemented timeout reversal factory constructor.The
createTimeoutReversalfactory constructor is comprehensively designed to create synthetic timeout reversal messages with complete order context. Key strengths:
- Properly extracts order information from public events
- Correctly sets status to
pendingfor timeout reversals- Handles both buy and sell order types appropriately
- Reconstructs all necessary order fields for proper UI display
- Properly handles nullable fields and provides sensible defaults
The implementation ensures that timeout reversal messages contain all the order information needed for proper state management and UI display.
lib/shared/widgets/notification_listener_widget.dart (2)
4-4: LGTM!Good use of import alias to avoid naming conflicts.
43-45: LGTM!Fixed 2-second duration is appropriate for notification messages.
lib/features/order/notfiers/order_notifier.dart (4)
2-15: LGTM!Good approach using a flag to prevent concurrent timeout processing and proper subscription management.
271-286: LGTM!Clear logic for determining maker vs taker role, consistent with the codebase patterns.
288-344: LGTM!Well-implemented real-time timeout detection with proper state validation and timeout handling.
346-370: LGTM!Proper notification handling and cleanup implementation.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
lib/features/order/notfiers/order_notifier.dart (1)
23-41: Proper synchronous implementation with async schedulingThe handleEvent method correctly maintains synchronous behavior while scheduling async timeout checks using Future.microtask. This addresses the previous review comment about keeping the method synchronous.
🧹 Nitpick comments (1)
lib/features/order/notfiers/order_notifier.dart (1)
51-54: Consider reducing log noise for empty messagesThe warning log for no messages might be too verbose for normal operation, especially during initial app startup.
- if (messages.isEmpty) { - logger.w('No messages found for order $orderId'); - return; - } + if (messages.isEmpty) { + logger.d('No messages found for order $orderId'); + return; + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
lib/features/order/notfiers/order_notifier.dart(2 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
lib/**/*.dart
📄 CodeRabbit Inference Engine (CLAUDE.md)
lib/**/*.dart: UseS.of(context).yourKeyfor all user-facing strings
Always checkmountedbefore using context after async operations
Files:
lib/features/order/notfiers/order_notifier.dart
**/*.dart
📄 CodeRabbit Inference Engine (CLAUDE.md)
**/*.dart: Remove unused imports and dependencies
Useconstconstructors where possible
Files:
lib/features/order/notfiers/order_notifier.dart
🧠 Learnings (2)
📓 Common learnings
Learnt from: chebizarro
PR: MostroP2P/mobile#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.
lib/features/order/notfiers/order_notifier.dart (15)
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/features//notifiers/**/.dart : Notifiers for complex state logic are placed in features/{feature}/notifiers/
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: Catrya
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. Do not suggest adding await to super.handleEvent() calls as this would cause compilation errors.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Encapsulate business logic in Notifiers
Learnt from: chebizarro
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 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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/**/*.dart : Always check mounted before using context after async operations
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to test/mocks.mocks.dart : DO NOT modify test/mocks.mocks.dart - it already has file-level ignores
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: All changes should pass flutter analyze before commit
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/services/nostr_service.dart : Nostr protocol interactions go through services/nostr_service.dart
Learnt from: chebizarro
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.
Learnt from: chebizarro
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.
Learnt from: chebizarro
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.
⏰ 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 (15)
lib/features/order/notfiers/order_notifier.dart (15)
2-7: Imports look good with proper organizationThe new imports are correctly added for the timeout detection functionality, including dart_nostr for public events, config for timeout constants, and models for data structures.
14-15: Instance variables properly declared for timeout handlingThe subscription variable and processing flag are well-defined to prevent race conditions and manage resource cleanup.
20-21: Constructor enhancement is appropriateAdding the public events subscription initialization in the constructor ensures real-time timeout detection starts immediately.
44-47: Good guard against concurrent timeout processingThe early return when
_isProcessingTimeoutis true prevents race conditions during sync operations.
56-70: Message sorting and state building logic is soundThe timestamp-based sorting and state building approach correctly processes messages in chronological order while tracking the latest gift wrap message.
72-82: Proper session cleanup integration in sync methodThe timeout cleanup check is well-integrated into the sync flow with appropriate session validation and provider invalidation.
94-96: Proper cleanup in finally blockThe finally block ensures the processing flag is reset even if exceptions occur, preventing permanent blocking of timeout processing.
162-172: Robust input validation for timeout checkingThe method properly validates the order state and gift wrap message before proceeding with timeout detection logic.
174-187: Proper public event validationThe code correctly retrieves and validates the public event, ensuring it exists and has the expected pending status before proceeding.
189-195: Sound timestamp comparison logicThe timestamp comparison between public event and gift wrap message is implemented correctly to detect timeout conditions.
205-243: Comprehensive maker scenario handlingThe maker scenario properly preserves the session while updating state and persisting timeout reversal messages. The error handling around message persistence is robust.
245-257: Proper taker scenario cleanupThe taker scenario correctly removes the session and returns appropriate cleanup indication.
275-289: Correct user role determination logicThe
_isCreatedByUsermethod properly determines maker vs taker based on the relationship between session role and order type.
292-347: Well-implemented real-time subscription handlingThe public events subscription includes proper concurrency control, timeout handling, and state verification at multiple points to ensure reliable timeout detection.
369-373: Proper resource cleanup in disposeThe dispose method correctly closes the subscription and calls super.dispose() to ensure proper cleanup.
- Document real-time timeout detection for waiting-buyer-invoice and waiting-payment states - Explain maker vs taker handling scenarios and session management - Include detection mechanism, persistence strategy, and key implementation details - Clarify system monitors 38383 events vs gift wrap timestamps for mostrod consistency
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
CLAUDE.md (3)
54-59: Document the hard-coded timeout constantsThe PR description mentions an 8 s detection window and 5 s storage window, but those values are missing here.
Readers will look for them in this section—please add the actual constants and reference their location inlib/core/config.dart(or wherever they live) so future changes remain discoverable.
57-59: Clarify the “38383 public events” data source“Monitors: 38383 public events” is terse and may confuse newcomers:
- Specify that 38383 is the Mostro relay public channel ID.
- Optionally link to / describe the provider or service that exposes these events (e.g.
orderEventsProviderinfeatures/order/providers/order_events_provider.dart).This small clarification prevents onboarding friction.
65-66: Add a file reference for the synthetic message factory
MostroMessage.createTimeoutReversal()is called out, but the file path isn’t.
Appending “(seelib/data/models/mostro_message.dart)" after the method name will help future maintainers locate the implementation quickly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
CLAUDE.md(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
CLAUDE.md
📄 CodeRabbit Inference Engine (CLAUDE.md)
Update CLAUDE.md when making architectural changes
Files:
CLAUDE.md
🧠 Learnings (2)
📓 Common learnings
Learnt from: chebizarro
PR: MostroP2P/mobile#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.
CLAUDE.md (5)
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to CLAUDE.md : Update CLAUDE.md when making architectural changes
Learnt from: chebizarro
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 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.
Learnt from: chebizarro
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.
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-20T01:48:43.335Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions are managed by core/mostro_fsm.dart
Learnt from: chebizarro
PR: #74
File: lib/features/trades/models/trade_state.dart:1-15
Timestamp: 2025-05-08T16:06:33.665Z
Learning: In the context of the Mostro Mobile app, the TradeState class is specifically constructed using the tradeStateProvider. While some fields are nullable (lastAction and orderPayload), they are still marked as required parameters to ensure they are explicitly considered during state construction.
⏰ 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
System automatically monitors public events (38383) and compares timestamps with latest gift wrap messages to detect when orders timeout from waiting states, ensuring UI consistency with mostrod state without requiring app restarts.
Summary by CodeRabbit
New Features
Improvements
Bug Fixes