Walletwasabi: Constant Errors

Created on 9 Jul 2020  路  7Comments  路  Source: zkSNACKs/WalletWasabi

Something is wrong. I keep getting these errors in every few seconds constantly on two different computers with two different wallets.

2020-07-09 15:41:10 ERROR       CoinJoinProcessor (73)  System.Net.Http.HttpRequestException: Bad Request
No such mempool or blockchain transaction. Use gettransaction for wallet transactions.
   at System.Net.Http.HttpResponseMessageExtensions.ThrowRequestExceptionFromContentAsync(HttpResponseMessage me) in C:\Users\user\Desktop\WalletWasabi\WalletWasabi\Extensions\HttpResponseMessageExtensions.cs:line 107
   at WalletWasabi.WebClients.Wasabi.WasabiClient.GetTransactionsAsync(Network network, IEnumerable`1 txHashes, CancellationToken cancel) in C:\Users\user\Desktop\WalletWasabi\WalletWasabi\WebClients\Wasabi\WasabiClient.cs:line 117
   at WalletWasabi.CoinJoin.Client.CoinJoinProcessor.Synchronizer_ResponseArrivedAsync(Object sender, SynchronizeResponse response) in C:\Users\user\Desktop\WalletWasabi\WalletWasabi\CoinJoin\Client\CoinJoinProcessor.cs:line 58
2020-07-09 15:41:15 ERROR       CoinJoinProcessor (73)  System.Net.Http.HttpRequestException: Bad Request
debug

All 7 comments

@molnard Do not release before this is fixed.

I think this function behaves incorrectly: public async Task<IActionResult> GetTransactionsAsync([FromQuery, Required] IEnumerable<string> transactionIds)

It throws an error when a tx isn't found instead of just not returning the txhex.

It was a symphtom of another issue, nevertheless it should still be fixed.

For the record, I could reproduce the error message earlier today.
Since the backend server restart, I can no longer reproduce them.

ACK for not start the testing game until this is fixed. On the other hand, I will create RC1 to test the whole deployment procedure if apple and its notarization are still working but it is for only internal testing.

It won't happen again: https://github.com/zkSNACKs/WalletWasabi/pull/3876

There's one question remaining though. What should we give back to the tx-hexes request when 1/5 tx request isn't i the mempool. Now we're giving feedback to the client that one of those txs aren't found and we don't serve any hex. Wouldn't it be better to serve those hexes those are found? Would a naive implementation result in performance issues?

This is good like this. Otherwise a user could give us a bunch of non-existent transactions and we'd do a very expensive RPC search operation for every one of them. Now when it finds the first bad one it returns bad request.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

yahiheb picture yahiheb  路  3Comments

MaxHillebrand picture MaxHillebrand  路  3Comments

davterra picture davterra  路  3Comments

2pac1 picture 2pac1  路  3Comments

nopara73 picture nopara73  路  3Comments