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

Feature request: ability to clear Send Idempotency IDs and force send #1162

Closed
jcraigk opened this issue Sep 8, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@jcraigk
Copy link

commented Sep 8, 2018

https://github.com/nanocurrency/raiblocks/wiki/RPC-protocol#send states You can (and should) specify a unique id for each spend to provide idempotency. For development purposes it would be helpful if RPC API could provide:

(1) Ability to clear all of these Idempotency IDs with one command
(2) Ability to provide "force" option to override node behavior of preventing duplicate send request

If it was deemed more secure to make (1) a CLI rai_node command, that would also be acceptable.

@PlasmaPower

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

For (2) you can simply not pass the id parameter in. We may remove that in the future, but we haven't yet.

@jcraigk

This comment has been minimized.

Copy link
Author

commented Sep 8, 2018

@PlasmaPower Yep that's what I'm doing currently. My suggestion for (2) was getting ahead of that potential requirement in the future (which I personally support).

@argakiig

This comment has been minimized.

Copy link
Collaborator

commented Sep 8, 2018

Is there a reason to not use publish or even rebroadcast instead?

@jcraigk

This comment has been minimized.

Copy link
Author

commented Sep 8, 2018

@argakiig in production, no. In fact, these features I'm suggesting shouldn't be used in production at all.

In development, I have a local database table storing transaction IDs. These are auto-increment, starting at 1 and counting up. When I flush the database and start over with ID 1, this means if I want to use the send idempotency feature, I need to start with a fresh data.ldb to clear the send IDs stored in its history. This incurs resource usage (and development slowdowns) to get the data.ldb up to date with current public block before transactions can be performed against the node.

One way I've circumvented this issue is by using GUIDs instead of standard integer IDs on transaction records in DB, and that works fine, but this got me thinking about development niceties especially if these idempotency IDs will be required in the future.

My naive opinion is that local node state like wallets, accounts, and idempotency IDs should be decoupled from public block storage. In such a scenario we'd have public_data.ldb and private_data.ldb or something. Deleting private_data.ldb would wipe local wallets, accounts and send IDs but you'd remain completely up-to-date in public_data.ldb with current latest public block. This would result in better app developer experience. I have no idea if it's possible/desirable from a protocol perspective, however.

@renesq

This comment has been minimized.

Copy link

commented Sep 10, 2018

Regarding separated databases... There has been a wallet_separation branch for months now, but it isn't merged yet, probably due to a lack of upgrade paths. #843

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.