Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add endpoint to stop retrying a transaction #24

Open
nguyer opened this issue Aug 22, 2022 · 1 comment
Open

Add endpoint to stop retrying a transaction #24

nguyer opened this issue Aug 22, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@nguyer
Copy link
Contributor

nguyer commented Aug 22, 2022

Currently if I submit a transaction with mistakes, evmconnect will continue to retry the transaction forever with no way to stop it. For example, I accidentally submitted a transaction with the wrong from address which had no funds to pay for gas. The transaction continually failed with no way to retry it. In instances like this, it would be good to have an endpoint that can be used to prevent retries from occurring.

@peterbroadhurst
Copy link
Contributor

So there's a couple of considerations here:

1. Practical / code

The Policy engine is responsible for updating the in-flight transactions, and it currently makes the assumption that it is the only thing updating those transactions.

I think this can be solved with a 202 on the DELETE with a DeleteRequested status that causes the delete to be actioned on the next time round the policy loop.

2. Nonce management

If the transaction is not the most recent in the sequence on the Nonce, or if it's been submitted to the node when you call delete, then deleting the transaction from the in-flight set being tracked by EVMConnect will leave you in a bad state. We could have a "bubble" where a nonce is unspent earlier, but nothing will fill in the gap.

The intention again is that the policy engine handles this. So I can handle this architecturally in the FFTM layer by having the deletion from DeleteRequested status handled by the policy engine itself. The simple policy engine implementation provided OOTB can simply action this by deleting it from storage. A more sophisticated policy engine implementation trained with knowledge of the business context behind the transactions, might analyze the status of the chain in more detail to see if a gap-fill etc. is required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants