feat(notifications): persist order cancellations in history with context#602
feat(notifications): persist order cancellations in history with context#602AndreaDiazCorreia wants to merge 3 commits into
Conversation
…essages - Add previousStatus parameter to notification extraction and event handling chain to differentiate cancellation reasons - Map Action.canceled to specific messages based on previous status (waiting-payment → seller inactivity, waiting-buyer-invoice → buyer inactivity) - Remove early return for canceled orders in NotificationDataExtractor; persist all cancellations to notification history - Replace custom showCustomMessage calls
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThreads previous order status and a user-initiated-cancel flag through notifiers into NotificationDataExtractor, which now persists Action.canceled notifications (optionally adding previous_status). Message mapper and localization add keys for seller vs buyer inactivity; auto-expiration uses the centralized notify path with a stable eventId. ChangesOrder cancellation notification for inactivity detection
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![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
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/features/order/notifiers/order_notifier.dart`:
- Around line 187-193: The notify call in order_notifier.dart that persists
auto-expiration cancellations (using
ref.read(notificationActionsProvider.notifier) and notify with Action.canceled)
must include a stable eventId to avoid duplicate history entries; update the
notify invocation to pass a deterministic eventId (for example a string like
"auto_expire:<orderId>" or a hash based on orderId + expirationTimestamp) via
the eventId parameter so repeated emissions of the same cancellation won't
create duplicate notifications.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c2f7c680-aecf-4829-b16e-91bc188b1315
📒 Files selected for processing (9)
lib/features/notifications/utils/notification_data_extractor.dartlib/features/notifications/utils/notification_message_mapper.dartlib/features/order/notifiers/abstract_mostro_notifier.dartlib/features/order/notifiers/order_notifier.dartlib/l10n/intl_de.arblib/l10n/intl_en.arblib/l10n/intl_es.arblib/l10n/intl_fr.arblib/l10n/intl_it.arb
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0b4f402eb9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![ermeme[bot]](https://avatars.githubusercontent.com/in/3690068?s=60&v=4){kind=small}
There was a problem hiding this comment.
Revisión Hermes
Veredicto: NO aprobaría este PR todavía.
Hay un problema funcional: el nuevo criterio usa solo previous_status para decidir si la cancelación fue por inactividad. Eso mezcla cancelaciones manuales con expiraciones reales y puede mostrar un mensaje falso en el historial.
Necesita un discriminador más preciso antes de entrar.
…activity timeouts
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@lib/features/order/notifiers/order_notifier.dart`:
- Around line 127-131: The code sets the user-initiated cancel flag via
AbstractMostroNotifier.markUserInitiatedCancel(orderId) before awaiting
mostroService.cancelOrder(orderId); if the async call throws the flag remains
set and later Action.canceled may be misclassified—wrap the await in a
try/catch, and in the catch call the corresponding rollback/unmark method (e.g.,
AbstractMostroNotifier.unmarkUserInitiatedCancel(orderId) or the actual method
that clears the flag) before rethrowing the error so the flag is only left set
on successful cancel.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0141b9cb-d938-47c6-ba1f-4589e8423f88
📒 Files selected for processing (3)
lib/features/notifications/utils/notification_data_extractor.dartlib/features/order/notifiers/abstract_mostro_notifier.dartlib/features/order/notifiers/order_notifier.dart
There was a problem hiding this comment.
Revisión Hermes
Veredicto: todavía no lo aprobaría.
El commit arregla el caso principal, pero dejó un hueco: el flag de markUserInitiatedCancel() se setea antes de await mostroService.cancelOrder(orderId) y nunca se limpia si esa llamada falla o no llega a emitir Action.canceled. Eso deja estado colgado y puede contaminar una cancelación posterior del mismo orderId.
La solución debería limpiar el flag en un try/finally o moverlo a una estructura con expiración/caducidad.
…prevent misclassification
There was a problem hiding this comment.
Hermes review
Approved.
The previous blocker is fixed: manual cancels are now tagged separately, the fallback is generic when the cancel was user-initiated, and the failure path now rolls back the marker so it does not leak into later events. The notification history behavior is now consistent for inactivity vs manual cancellation.
1 participant
Summary
Closes #535.
When an order is canceled due to counterparty inactivity in
waiting-paymentorwaiting-buyer-invoice, the user previously only saw a transient SnackBar — the event never reached the notifications screen (bell icon), so they could not review what happened to the order afterwards.This PR persists every
Action.canceledevent to the notification history with a context-aware message based on the order's previous status:waiting-payment→ "The seller did not continue the order. The order has been cancelled."waiting-buyer-invoice→ "The buyer did not continue the order. The order has been cancelled."Changes
NotificationDataExtractor: newpreviousStatusparameter;Action.canceledno longer returnsnull(which previously skipped persistence) and instead emitsNotificationDatawithprevious_statusinvalues.NotificationMessageMapper.getMessageKeyWithContext: resolves the correct localization key forAction.canceledbased onprevious_status.AbstractMostroNotifier.subscribe(): capturespreviousStatus = state.statusbeforestate.updateWith(msg)and forwards it throughhandleEvent→ extractor.AbstractMostroNotifier.handleEvent(): removed the now-redundantshowCustomMessage('orderCanceled')call — the centralizednotify()path already shows the SnackBar and persists to history.OrderNotifier: forwardspreviousStatusin itshandleEventoverride and converts the pending-order-expiryshowCustomMessage('orderCanceled')to anotify(Action.canceled, ...)call so it also appears in the history.notification_order_canceled_by_seller_inactivity_messageandnotification_order_canceled_by_buyer_inactivity_messagetoen,es,it,de,fr.Test plan
fvm flutter analyze→ no issues (verified)fvm flutter test→ all tests pass (verified, 369/369)Action.canceled, open the notifications screen and verify the "seller did not continue" message appearsSummary by CodeRabbit
New Features
Localization