The app must:
If an order is in status waiting-buyer-invoice or waiting-payment:
- When the taker receives
action:canceled, it must delete the taker session and display the canceled message
- When the maker receives
action:neworder with the same order ID, it must return the maker’s order to Pending.
- When the maker receives
action:canceled it must delete the maker session and display the canceled message
We need to wait until this PR is merged:
MostroP2P/mostro#530
Current behavior to be replaced:
Currently, the app works as follows:
When taking an order, the app creates a session for that order and receives a gift wrap with either add-invoice and status waiting-buyer-invoice (if it was a sell order) or pay-invoice and waiting-payment (if it was a buy order).
The app is subscribed to 38383 events from Mostro.
If the user does not respond within X time, mostrod publishes a 38383 event for that order with status Pending, but it does not notify either the taker or the maker (their last message in the app remains add-invoice or pay-invoice).
When the app detects that Mostro has published a 38383 event for that order with status Pending, it assumes the user didn’t respond in time and removes the session for that order.
Related documentation:
https://github.com/MostroP2P/mobile/blob/main/docs/architecture/TIMEOUT_DETECTION_AND_SESSION_CLEANUP.md
However, if the Mostro instance uses multiple relays and one of them experiences a delay, that relay might publish the Pending event after the others have already published more recent events, such as add-invoice or pay-invoice. As a result, the app may incorrectly interpret the order as expired and remove the session, even though the user actually responded in time.
The app must:
If an order is in status
waiting-buyer-invoiceorwaiting-payment:action:canceled, it must delete the taker session and display the canceled messageaction:neworderwith the same order ID, it must return the maker’s order to Pending.action:canceledit must delete the maker session and display the canceled messageWe need to wait until this PR is merged:
MostroP2P/mostro#530
Current behavior to be replaced:
Currently, the app works as follows:
When taking an order, the app creates a session for that order and receives a gift wrap with either
add-invoiceand statuswaiting-buyer-invoice(if it was a sell order) orpay-invoiceandwaiting-payment(if it was a buy order).The app is subscribed to 38383 events from Mostro.
If the user does not respond within X time, mostrod publishes a 38383 event for that order with status
Pending, but it does not notify either the taker or the maker (their last message in the app remainsadd-invoiceorpay-invoice).When the app detects that Mostro has published a 38383 event for that order with status
Pending, it assumes the user didn’t respond in time and removes the session for that order.Related documentation:
https://github.com/MostroP2P/mobile/blob/main/docs/architecture/TIMEOUT_DETECTION_AND_SESSION_CLEANUP.md
However, if the Mostro instance uses multiple relays and one of them experiences a delay, that relay might publish the Pending event after the others have already published more recent events, such as add-invoice or pay-invoice. As a result, the app may incorrectly interpret the order as expired and remove the session, even though the user actually responded in time.