[BUG] tx rejected: already have transaction

[elderapo]

I've been getting this error when broadcasting brand new transactions (none besides me before this broadcast could possibly have seen this tx).

3 INVALID_ARGUMENT: tx rejected: already have transaction

I've been using grpc interface and this error only happens when my client is connected to bchd.greyh.at:8335, it works just fine for bchd.imaginary.cash:8335. Maybe it has already been fixed and just greyh is using an outdated version? Haven't had time to spin up and sync my own nodes to test that theory though...

As a workaround I've been catching errors and checking if it's error code is 3 and if so just treated tx as successfully broadcasted (and calculating its txid on my own instead of using one from the response).

[zquestz]

We need to track this down for sure. Right now bchd.greyh.at is just using master. @jcramer @cpacia can you help me debug?

[jcramer]

can you help me debug?

@zquestz I'll will take a look today.

[elderapo]

Seems like v0.17.0 & v0.17.1 work just fine so it must be something on master :)

[jcramer]

I'm not able to reproduce this issue, and looking at the code path I'm not seeing anything obvious that would cause it. The travis regtest tests has several uses of grpc SubmitTransaction endpoint and those tests pass, so I'm not sure that it must be something on master.

[zquestz]

I also am not able to reproduce this bug report. I am able to send transactions just fine on bchd.greyh.at... I also looked over the code that returns that error, I don't see a way that can happen without the node seeing the hash before... Do you have a tx hash so I can look at the logs?

[elderapo]

There you go @zquestz: d7ad6a4f2db4ddf152a265937895f3e717a15717d06e5bb8020bbea01dd47970. Maybe worth mentioning that I am broadcasting transactions using https://github.com/simpleledgerinc/grpc-bchrpc-node.

[elderapo]

Oh and there is one more thing... Broadcast throws: Error: 3 INVALID_ARGUMENT: tx rejected: already have transaction d7ad6a4f2db4ddf152a265937895f3e717a15717d06e5bb8020bbea01dd47970 and transaction lookup right after throws: Error: 5 NOT_FOUND: transaction not found.