fix: ensure cancellation detection for orders in waiting states#252
Conversation
WalkthroughThe changes introduce explicit handling of order cancellations in both documentation and implementation. The system now detects cancellations via public events, cleans up sessions for both maker and taker roles, notifies the user, and navigates back to the order book. Documentation was updated to describe this unified cancellation and timeout detection process. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant OrderNotifier
participant EventMonitor
participant UI
EventMonitor->>OrderNotifier: Public event (status: canceled or pending)
OrderNotifier->>OrderNotifier: _checkTimeoutAndCleanup()
alt Event is canceled & newer
OrderNotifier->>OrderNotifier: Delete session (maker/taker)
OrderNotifier->>UI: Show cancellation notification
OrderNotifier->>UI: Navigate to Order Book
else Event is pending & newer
alt Maker scenario
OrderNotifier->>OrderNotifier: Persist timeout reversal, update state
else Taker scenario
OrderNotifier->>OrderNotifier: Delete session
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15 minutes Possibly related PRs
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 (6)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (5)
✨ 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. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
CLAUDE.md(1 hunks)lib/features/order/notfiers/order_notifier.dart(4 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 use localized strings instead of hardcoded text
Pass BuildContext to methods that need localization
Always use latest APIs (e.g.,withValues()instead ofwithOpacity())
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 (8)
📓 Common learnings
Learnt from: chebizarro
PR: MostroP2P/mobile#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.
📚 Learning: mostroservice methods like takebuyorder() and takesellorder() return future and trigger side e...
Learnt from: chebizarro
PR: MostroP2P/mobile#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:
CLAUDE.mdlib/features/order/notfiers/order_notifier.dart
📚 Learning: in abstractmostronotifier, state updates occur for all messages regardless of timestamp to hydrate t...
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.
Applied to files:
CLAUDE.mdlib/features/order/notfiers/order_notifier.dart
📚 Learning: in abstractmostronotifier, the handleevent method is synchronous and returns void, not future....
Learnt from: Catrya
PR: MostroP2P/mobile#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/order_notifier.dart
📚 Learning: applies to lib/core/mostro_fsm.dart : order state transitions must be managed by `core/mostro_fsm.da...
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-30T14:10:43.895Z
Learning: Applies to lib/core/mostro_fsm.dart : Order state transitions must be managed by `core/mostro_fsm.dart`
Applied to files:
lib/features/order/notfiers/order_notifier.dart
📚 Learning: in the mostro protocol, an order cannot be canceled unless it has a valid orderid, so null checks on...
Learnt from: chebizarro
PR: MostroP2P/mobile#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/order_notifier.dart
📚 Learning: encapsulate business logic in notifiers...
Learnt from: CR
PR: MostroP2P/mobile#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-30T14:10:43.895Z
Learning: Encapsulate business logic in Notifiers
Applied to files:
lib/features/order/notfiers/order_notifier.dart
📚 Learning: in the orderstate refactor, public keys should be accessed via `tradestate.peer?.publickey` from the...
Learnt from: chebizarro
PR: MostroP2P/mobile#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/features/order/notfiers/order_notifier.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 (2)
lib/features/order/notfiers/order_notifier.dart (1)
25-34: LGTM! Good defensive programming.Adding the cancellation check prevents conflicting operations between timeout detection and cancellation handling.
CLAUDE.md (1)
74-81: Excellent documentation of the cancellation handling.The documentation clearly describes the cancellation detection mechanism and its behavior, with accurate references to the implementation. This will be valuable for future maintenance.
- Fix cancellation detection for waiting states in _checkTimeoutAndCleanup() - Delete sessions when orders are canceled from waiting states - Add cancellation notification and navigation - Document cancellation detection in waiting states
- Use showCustomMessage('orderCanceled') instead of showInformation()
- Add orderCanceled case to notification_listener_widget.dart
- Add orderCanceled key to all ARB localization files (en, es, it)
Summary by CodeRabbit
New Features
Documentation
Localization
Bug Fixes