Improve handling of failed trades and offers #3566
Conversation
chimp1984
commented
Nov 6, 2019
chimp1984
commented
- Check if deposit tx is null
- Check if trade fee tx is rejected
- Listen to reject tx errors
- Cleanup addressEntryList
- Prevent opening disputes with if deposit tx is null
- Add null checks
- Improve logs
- Cleanups
- Check if deposit tx is null - Check if trade fee tx is rejected - Listen to reject tx errors - Cleanup addressEntryList - Prevent opening disputes with if deposit tx is null - Add null checks - Improve logs - Cleanups
In case the deposit tx is null we show a popup telling the user to move the trade to failed trades after a restart if the problem persist.
| formatter.formatCoinWithCode(balance), e.getAddressString(), e.getOfferId()); | ||
| log.warn(message); | ||
| if (lockedUpFundsHandler != null) { | ||
| lockedUpFundsHandler.accept(message); |
There was a problem hiding this comment.
Is there something preventing automatic opening of disputes here, rather than asking the trader to do it manually?
There was a problem hiding this comment.
I am not sure how to reproduce that and if deposit tx is null then the user cannot open a dispute.
| trade.setErrorMessage(newValue.getMessage()); | ||
| rejectedTxErrorMessageHandler.accept(Res.get("popup.warning.trade.txRejected", | ||
| finalDetails, trade.getShortId(), txId)); | ||
| tradeManager.addTradeToFailedTrades(trade); |
There was a problem hiding this comment.
It would be nice to avoid losing the offer fee tx and revert this to an active offer.
There was a problem hiding this comment.
I feat that is too complex to get it right. It should be exceptional case anyway. And users can request for reimbursement.
There was a problem hiding this comment.
At this point just getting things more stable is good. Perhaps we could look at it if it's recurring event that people lose their fee this way.
| UserThread.execute(() -> { | ||
| RejectMessage rejectMessage = (RejectMessage) message; | ||
| String msg = rejectMessage.toString(); | ||
| log.error(msg); |
There was a problem hiding this comment.
I think this should be warning log level
There was a problem hiding this comment.
Ok. I will change it.
| // send out the funds to the external wallet. As this cleanup is a rare situation and most users do not use | ||
| // the feature to send out the funds we prefer that strategy (if we keep the address entry it might cause | ||
| // complications in some edge cases after a SPV resync). | ||
| swapTradeEntryToAvailableEntry(offerId, AddressEntry.Context.TRADE_PAYOUT); |
There was a problem hiding this comment.
Is there a risk of address reuse by re-labeling this address?
There was a problem hiding this comment.
I think it was never used in that use case (failed trade), so its a fresh address.
| "That should never happen. trade ID=" + trade.getId()); | ||
| } | ||
| } else { | ||
| tradeTxException.set(new TradeTxException(Res.get("error.closedTradeWithNoDepositTx", trade.getShortId()))); |
There was a problem hiding this comment.
This means there are no funds locked in, should it still be part of the tradesIdSet representing locked in funds?
There was a problem hiding this comment.
Hm... Not sure. But after the pending trade has been moved to failed trade I think the tradesIdSet is correct again. All those cases are very hard to reproduce/test...
There was a problem hiding this comment.
Looks like it will work due to how the result of getSetOfFailedOrClosedTradeIdsFromLockedInFunds is used, but perhaps the function name is a bit misguiding since there is no locked in fund. Could return null there and filter out nulls before collect().
