-
Notifications
You must be signed in to change notification settings - Fork 146
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
feat: delayed finalization #214
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot. We have to keep in mind that the default behaviour changes now from "never finalize" to "finalize right away".
I think it would be better to change the default value so something like 2 seconds instead of 0. It is a more sane default as it forces client devs to think about those two states when working with the dev node. Instead of assuming they are the same.
cc @wottpal
It is currently opt-in only by specifying the Perhaps the notes in the command description/readme around using 'a value of 0 for instant finalization' should simply be replaced with a suggestion of 2 seconds? The command example in the readme suggests 5 seconds, so I can standardise all of the documentation to 2 seconds. |
thanks for the heads up, @athei. really appreciate that this is coming to |
I did misread the code. Didn't notice it was an However, I don't think having blocks to be never finalized is of any use (current behaviour). I suggest removing the |
Updated as suggested, where it now defaults to delayed finalization of 1 second but still allows developer to override. Note that the first manual test in the original PR comment above no longer applies, as that was testing the default method remained unchanged. |
Adds
--finalize-delay-sec
cli argument, based on the great work by @shunsukew at inkdevhub/swanky-node#61.Manual testing by starting node with/without option, along with example contract upload:
Closes #160