[bisq-network/bisq] Fix issue of Trade Step 1 validation done too soon (#5746)

[chimp1984]

Ah the above would not work as the ordinal of SELLER_PUBLISHED_DEPOSIT_TX is < SELLER_SAW_ARRIVED_DEPOSIT_TX_PUBLISHED_MSG and we do not allow setting states to lower states. 

All those states:
```
SELLER_SENT_DEPOSIT_TX_PUBLISHED_MSG(Phase.DEPOSIT_PUBLISHED),
        SELLER_SAW_ARRIVED_DEPOSIT_TX_PUBLISHED_MSG(Phase.DEPOSIT_PUBLISHED),
        SELLER_STORED_IN_MAILBOX_DEPOSIT_TX_PUBLISHED_MSG(Phase.DEPOSIT_PUBLISHED),
        SELLER_SEND_FAILED_DEPOSIT_TX_PUBLISHED_MSG(Phase.DEPOSIT_PUBLISHED),
```

are only used in the  PendingTradesViewModel and as we should ignore those anyway we could decide to NOT set them, so the setting of the SELLER_PUBLISHED_DEPOSIT_TX would not get blocked (a comment why we dont set them and marking those states deprecated would be good as well).

The order of the states is a relict from the old trade protocol and also sometimes there is no deterministic order of events.
The state handling got too fine grained for the level where we use it.

Regarding the failed broadcast:
We use the default TxBroadcaster.Callback.onTimeout method which calls onSuccess at those expected false positive failures (see comment there). So the code in SellerPublishesDepositTx should work for those cases as it is. Would have been an issue anyway otherwise as the code at onSuccess is important to be executed and it would have led to bugs if that would not get called.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/5746#issuecomment-939879623
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20211011/92906898/attachment.htm>