DAPI returns "state transition already in chain" on invalid transactions

[pshenmic]

Expected Behavior

DAPI should return a specific and human readable reason why the transaction was rejected

Current Behavior

When you are broadcast invalid state transition through broadcastStateTransition GRPC query, I always see state transition already in chain error

However, if you check the transaction with check_tx query of the Tenderdash RPC, we can see that transaction invalid, and the reason why it is failing

Possible Solution

Steps to Reproduce (for bugs)

1. Create invalid transaction (for example change nonce)
2. Try to broadcast it via GRPC broadcastStateTransition
3. state transition already in chain error returns in the response

Context

Your Environment

• Version used:
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop, server, or mobile):
• Link to your project:

[shumkov]

Here is a combination of two problems:

1. A bug in DAPI client retry logic was introduced in feat(sdk)!: detect stale nodes #2254: it retires when it is not supposed to retry. I will provide a fix soon.
2. If we broadcast an invalid ST a second time we are getting just state transition already in cache and there is no way to see validation errors on the client side. This happens because of invalid tx cache. I remember we enabled it because of some invalid tx ghosts jumping between node mempools forever.

@lklimek @QuantumExplorer I see two solutions for the second problem:

1. Disabling invalid tx cache and adding tx expiration period instead.
2. Storing tx result in the tx cache so instead of state transition already in cache for both invalid and valid txs we will get the tx result and pass it back to the user.

I prefer the second solution.

[shumkov]

@lklimek, do you propose to call check_tx in DAPI if we get state transition already in cache form broadcast_tx? Unfortunately, It won't help because if the tx was already committed, you will get a new error due to invalid nounces. If it was invalidated, then there is a chance that it was invalidated by block processing with additional validations, so check tx will say, ' Everything is fine. '

Here is the PR for the first problem #2261

[shumkov]

@lklimek have you deleted your comment? :)))

[lklimek]

@lklimek have you deleted your comment :)))

Yep, I didn't think you have already seen it. Sorry. I realized check tx is not solution.

[shumkov]

@pshenmic we are working on defining a solution for this problem. I will let you know when we have something.

[shumkov]

The problem is fixed #2270. We still need to switch to new unconfirmed txs filter when dashpay/tenderdash#963 is done