Track failed trades with "locked up" trade process screen

[cbeams]

The trade process screen stays in this state indefinitely

We've had several of these show up over the last 1–2 weeks. All (I believe) have been Cash App trades. It is unknown if this is just a coincidence; I cannot think of a reason why a specific payment method would cause this kind of behavior.

In all cases thus far (again, I believe—@keo-bisq can confirm—the deposit transaction failed to broadcast, but the deposit transaction field in the trade is populated, with a successful deposit transaction from a different trade. This is very strange behavior, and it took me a moment to realize fully what was going on. I have seen this deposit transaction swapping happen once or twice before, many weeks ago. I'm not sure if the details were ever recorded.

In any case, here is a relevant chunk of the log for trade CTBWG (as seen in the screenshot above): Note especially the depositTx is null and Timeout reached WARN and ERROR statements.

Mar-01 18:48:07.940 [JavaFX Application Thread] INFO  o.b.c.TransactionBroadcast: broadcastTransaction: TYPE:  TX 3ac8762178d0a39e4f82d46f39f55a6f5aaa2379899eb0ed007d8a2a54cf5883 seen by 0 peers 
Mar-01 18:48:07.940 [JavaFX Application Thread] INFO  i.b.c.b.w.BtcWalletService: swap addressEntry with address 14JTxUcCpJGVB7nZGsMf5Bw29o4QX3eksZ and offerId CTBWG-2844ed59-165f-4a11-967e-7c8669eebddb-066 from context OFFER_FUNDING to available 
Mar-01 18:48:07.940 [JavaFX Application Thread] INFO  i.b.c.t.Trade: Set new state at BuyerAsTakerTrade (id=CTBWG): TAKER_PUBLISHED_TAKER_FEE_TX 
Mar-01 18:48:07.941 [JavaFX Application Thread] INFO  i.b.c.t.TaskRunner: Run task: BuyerAsTakerCreatesDepositTxInputs 
Mar-01 18:48:07.942 [JavaFX Application Thread] INFO  o.b.w.Wallet: Completing send tx with 1 outputs totalling 0.010064 BTC and a fee of 0.00 BTC/kB 
Mar-01 18:48:07.948 [JavaFX Application Thread] INFO  o.b.w.Wallet:   with a fee of 0.00033507 BTC/kB, 0.000064 BTC for 191 bytes 
Mar-01 18:48:07.949 [JavaFX Application Thread] INFO  o.b.w.Wallet:   completed:   b5b5a3607e2efdda62247f0a9c23f325cc4fd084db770889079c47d1fd71e33d
     in   PUSHDATA(71)[304402207e0700d8f37793bc6088618517afc5d4511cb2347fcfb8532351b662b0217a2702200efb67908bc235bd0962a4a60ce846ce5c1eb5c526b4385bfa3e3d2c9b7316d201] PUSHDATA(33)[028b06a20e640c0c14a56077be67f8f209318d966d36656ea85e3e2a2c2bf914ba] 0.010128 BTC (1012800)
          outpoint:3ac8762178d0a39e4f82d46f39f55a6f5aaa2379899eb0ed007d8a2a54cf5883:1 hash160:0012b4f2bddbe53e1622ecada5920b1bddc657db
     out  DUP HASH160 PUSHDATA(20)[89237f50d2a0de44b6916cb2ef85e2936607b234] EQUALVERIFY CHECKSIG 0.010064 BTC (1006400) ScriptPubKey: 76a91489237f50d2a0de44b6916cb2ef85e2936607b23488ac Address:1DW86gLkuBFritV1kM8a2WumX9xBVZx8hX 
     fee  0.000064 BTC for 191 bytes (33 Satoshi/Byte)
     prps USER_PAYMENT

Mar-01 18:48:07.950 [JavaFX Application Thread] INFO  i.b.c.t.TaskRunner: Run task: TakerSendPayDepositRequest 
Mar-01 18:48:07.951 [JavaFX Application Thread] INFO  o.b.w.WalletFiles: Saving wallet; last seen block is height 511548, date 2018-03-01T23:44:12Z, hash 00000000000000000048909acfb3872ba3407cd7233853776f5e84f17c8cbd86 
Mar-01 18:48:07.957 [JavaFX Application Thread] INFO  o.b.w.WalletFiles: Save completed in 5.367 ms 
Mar-01 18:48:07.957 [JavaFX Application Thread] INFO  o.b.w.WalletFiles: Saving wallet; last seen block is height 511548, date 2018-03-01T23:44:12Z, hash 00000000000000000048909acfb3872ba3407cd7233853776f5e84f17c8cbd86 
Mar-01 18:48:07.963 [JavaFX Application Thread] INFO  o.b.w.WalletFiles: Save completed in 5.181 ms 
Mar-01 18:48:31.293 [JavaFX Application Thread] INFO  i.b.c.p.p.PriceFeedService: request from provider http://xc3nh4juf2hshy7e.onion/ 64.016 sec. after last request 
Mar-01 18:48:36.506 [JavaFX Application Thread] INFO  i.b.c.p.p.PriceFeedService: Received new MarketPrice(currencyCode=USD, price=10946.3, timestampSec=1519948037, isExternallyProvidedPrice=true) from provider http://xc3nh4juf2hshy7e.onion/ after 5.213 sec. 
Mar-01 18:48:50.621 [JavaFX Application Thread] WARN  i.b.c.t.Trade: depositTx is null 
Mar-01 18:48:50.622 [JavaFX Application Thread] WARN  i.b.c.t.Trade: depositTx is null 
Mar-01 18:49:21.116 [JavaFX Application Thread] INFO  i.b.n.p.p.PeerManager: We have 12 connections open. Our limit is 12 
Mar-01 18:49:33.308 [JavaFX Application Thread] INFO  i.b.c.p.p.PriceFeedService: request from provider http://xc3nh4juf2hshy7e.onion/ 62.015 sec. after last request 
Mar-01 18:49:38.017 [InputHandler-3qcka3rhrde7j6zc.onion:9999] INFO  i.b.n.p.n.Connection$InputHandler: proto is null because protoInputStream.read()=-1 (EOF). That is expected if client got stopped without proper shutdown. 
Mar-01 18:49:38.018 [JavaFX Application Thread] INFO  i.b.n.p.p.PeerManager: onDisconnect called: nodeAddress=Optional[3qcka3rhrde7j6zc.onion:9999], closeConnectionReason=CloseConnectionReason{sendCloseMessage=false, isIntended=false} NO_PROTO_BUFFER_ENV 
Mar-01 18:49:38.018 [JavaFX Application Thread] INFO  i.b.n.p.p.p.PeerExchangeManager: onDisconnect closeConnectionReason=CloseConnectionReason{sendCloseMessage=false, isIntended=false} NO_PROTO_BUFFER_ENV, nodeAddressOpt=Optional[3qcka3rhrde7j6zc.onion:9999] 
Mar-01 18:49:40.464 [JavaFX Application Thread] INFO  i.b.c.p.p.PriceFeedService: Received new MarketPrice(currencyCode=USD, price=10939.84, timestampSec=1519948127, isExternallyProvidedPrice=true) from provider http://xc3nh4juf2hshy7e.onion/ after 7.156 sec. 
Mar-01 18:49:50.620 [JavaFX Application Thread] WARN  i.b.c.t.Trade: depositTx is null 
Mar-01 18:49:50.620 [JavaFX Application Thread] WARN  i.b.c.t.Trade: depositTx is null 
Mar-01 18:49:59.901 [JavaFX Application Thread] ERROR i.b.c.t.p.TradeProtocol: Timeout reached. TradeID=CTBWG-2844ed59-165f-4a11-967e-7c8669eebddb-066, state=TAKER_PUBLISHED_TAKER_FEE_TX 
Mar-01 18:49:59.908 [JavaFX Application Thread] WARN  i.b.c.t.p.TradeProtocol: cleanupTradableOnFault tradeState=TAKER_PUBLISHED_TAKER_FEE_TX 

In any case, these are failed trades, and should be handled for reimbursement like others we've done in the past. The good news is that they are still coming in properly to arbitration, so they can be handled in a controlled manner.

I'm setting up affected trades that have come into my arbitration queue (2 so far) for reimbursement as individual issues under the epic at bisq-network/support#76. @keo-bisq, please do the same. You can just follow suit with the issues I've already created, like bisq-network/support#77.

[cbeams]

@ManfredKarrer, if you have any intuitions about what might be causing this behavior, please weigh in, thanks.

[cbeams]

@keo-bisq, note that this is the closing ticket message I'm giving my trades affected by this bug:

Closing as a failed trade. The trading amount and security deposits are safe, they never left buyer and seller Bisq wallets. Mining and trading fees were lost, however, on both maker and taker sides, and will be reimbursed. Please see and subscribe to the GitHub issue at [[[LINK TO SUPPORT ISSUE]]] for further details.

Please do not hesitate to continue trading on Bisq in the meantime. We have seen this issue crop up several times now, but the vast majority of trades are problem free. We'll get this patched up in an upcoming release. Thanks to both parties.

Where [[[LINK TO SUPPORT ISSUE]]] is, e.g. https://github.com/bisq-network/support/issues/77 (in the case of trade CTBWG.

[ManfredKarrer]

The depositTx is null log is nothing critical, the log should be removed in the code....

Seems the peer never returned the deposit tx. The trade fee tx shows that the funds are not spent. https://blockchain.info/tx/3ac8762178d0a39e4f82d46f39f55a6f5aaa2379899eb0ed007d8a2a54cf5883

The user should delete the spv file to resync wallet and if he has no other trades open he can delete the db file: /Bisq/btc_mainnet/db/PendingTrades

That should bring all into a normal state again.

[cosmasta]

My trade also failed. I bought from the same seller a day before. Could it be that the advert was not removed after a taker initiated payment? Or my network was just slow and timed out? I lost the fee. What to do? TxID: a0cb5a19d305a578b075ca6bbda49404264ad437f060de738e8e84cc7adcc554

[cbeams]

Issue moved to bisq-network/support #86 via ZenHub