The buyers order state doesn't update after the vendor fulfills

[rmisio]

This is a port of OpenBazaar/openbazaar-desktop#1505. The main issue is that the buyer can't complete the order after the vendor fulfills because the order state remains AWAITING_FULFILLMENT even though the order does get a vendorOrderFulfillment data object.

The JSON of the order is included in the referenced client bug.

[jjeffryes]

@cpacia did you have any luck with reviewing the data from Monique's node to find out how this happened?

[placer14]

@cpacia Can you update this issue?

[jjeffryes]

We have an additional report of this issue from Zendesk, I think it's been validated.

[cpacia]

I think this has been fixed. Also no reports of this in a very long time. Closing. Can repo if we get any reports.

[jjeffryes]

I am reopening this issue because both Brian and I are seeing it when testing Haven, but I don't think it's a Haven-specific issue.

[placer14]

I've found one scenario where this can be recreated:

1. Buyer starts order and pays with external wallet.
2. Buyer node fails to detect payment locally.
3. Vendor detects payment and fulfills order as normal.
4. ORDER_FULFILLMENT message (when sent online/directly) is rejected by buyer because payment isn't detected and ready to continue yet. Since the message was sent directly and received, there is no retry logic to handle applying the fulfillment message again. Thus the order becomes stuck with no logic to allow the order to progress further.

The proposed fix looks something like this:

1. Merge Manually send order messages and trigger offline message scan #1584 which captures ORDER messages on sending side for later resending if needed.
2. When ORDER processing fails on either side, send a new message type ORDER_PROCESSING_FAILURE (or similar) to the counter-party.
3. Add logic to handle ORDER_PROCESSING_FAILURE by gathering all ORDER messages (enabled by behavior in (1)) and resending them to the other party (in order). The other party would receive and apply each message.

Some failure scenarios to consider:

1. ORDER message doesn't exist to resend. How to handle stuck order in this case?
2. ORDER message being resent is already applied and not needed. Maybe the ORDER_PROCESSING_FAILURE can indicate the next steps that it expects, or send a copy of the contract in its current state for detecting what is needed next?
3. ORDER message being resent is the next needed but still fails to be applied properly. We would want to ensure that this retry scenario doesn't keep happening over and over when it will never work. Unsure how to handle this case, yet.
4. ORDER_PROCESSING_FAILURE might occur when counter-party is offline, necessitating sending the FAILURE message offline. This could also mean the resent messages might also come back via offline send, which has handling logic already but if the offline messages have deterministic pointers and the other party has already downloaded/processed them, and ignore them. We may need to preemptively clear the offlinemessages pointer list to ensure this case doesn't cause resend attempts to be ignored?

These are the only obvious concerns I can think of.