The buyer receives the takerFeeTxId with the frist message, but at the moment it is not published. To reflect that he also keeps it in the process model and
at the next message when the fee tx is published he sets it in the Trade.
Remove
`checkArgument(!walletService.getAddressEntry(id, AddressEntry.Context.MULTI_SIG).isPresent(),
"addressEntry must not be set here.");
`
as it causes failure if a taker takes same offer after certain error conditions again.
Set trash button disabled if the tx chain is valid to avoid that users move to failed while trade is valid to be completed.
Contract: Add isMyRoleMaker method
Trade: Add hasErrorMessage and isTxChainInvalid methods
The info icon next to the trade ID is then a warning icon (should be red but css is not my best friend) and if opening trade details window we also color the missing txs red with a warn icon and tooltip.
When clicking the trash button a popup is displayed with detail info.
At failed trades there is a "undo" icon for reverting the trade back to pending (if user wants to open mediation, etc).
All the automatic handling of the failed trades and popups are removed as it never worked well and just confused users...
In next commits we will add more instructions what a user should/can do for diff. error cases.
TradeManger:
- Remove all the failed checks at initPendingTrade.
- Remove tradesWithoutDepositTx
- Remove tradesForStatistics as it was never read
- Remove cleanUpAddressEntries
- Rename addTradeToClosedTrades to onTradeCompleted
TxIdTextField accepts a null for tx ID and shows then red colored N/A and a warning icon.
HyperlinkWithIcon exposed the icon to be accessible for style change.
DebugWindow was updated for one variation of the trade protocol (other is missing still).
Trade detail window show now always all 4 mandatory txs.
Beside that this commit has some cleanups and null pointer fixes (when testing error scenarios i got those NP).
Before we did not apply messages if the peers key was null which can be the case at protocol start for maker side (takers key is not set yet). Makers key is in offer and available from the start.
Fix incorrect setPubKeyRing call in BuyerAsTakerProtocol and BuyerProtocol. Only taker can set it from offer. This bug was introduce in past commits of this branch.
Move FluentProtocol to own class file
Close open offer in task instead at state listener
Remove state listener
Remove default timeout as not used anymore
Add onWithdrawCompleted method to clean up when trade completed
Rearrange code in TradeProtocol
Rename doHandleDecryptedMessage to onTradeMessage
Rename doApplyMailboxTradeMessage to onMailboxMessage
- Add time outs per request/response cycle.
- Use custom timeouts
- Stop timeout if condition not met
- Allow multiple condition calls (all need to be true)
- Move processModel.setTradeMessage(tradeMessage); and processModel.setTempTradingPeerNodeAddress(peerNodeAddress); calls to FluentProcess
- Add Validator.isTradeIdValid method
- Replace Validator.checkTradeId(processModel.getOfferId(), tradeMessage); by isTradeIdValid in FluentProcess
- Add DisputeEvent
- Derive info string from message or event at handleTaskRunnerSuccess
- Add from method
- Add withTimeout method
- Add BuyerEvent.STARTUP
- Rename onMessage to on
- Rename onEvent to on
- Rename tradeMesage to message
- Rename sener/peerNodeAddress to peer
Add ifInPhase method to allow alternative phases. We can have parallel branches how we reach a new state, e.g. receiving the tx from network or receiving it from the peer. no guarantee which will happen first.
Allow phase transition to skip a future phase as we have phases only relevant for one role. This is not good for treading it as a state machine state, we need to redesign the state/phase handling...
Reason: the other model was already tested quite a lot and seems to work correctly.
We gain a lot of resiliance with min. costs (repeated mailbox messages - as they are the same
they will not cause higher number of msg, just a bit more traffic)
Call BuyerSetupPayoutTxListener before BuyerSendCounterCurrencyTransferStartedMessage
We will change BuyerSendCounterCurrencyTransferStartedMessage so that it
does not complete until the message has been ACKed by the peer.
It is more transparent to leave the task uncompleted and if it is the last task we dont have issues.
The caller would not get the result handler called though until all is completed. But the result handler in the UI was anyway empty.
