-
Notifications
You must be signed in to change notification settings - Fork 285
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(connector-besu): request param: wait for ledger tx receipt #685
Labels
Comments
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Mar 19, 2021
…ledger-cacti#685 This is work in progress ----------------------------------- Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Mar 22, 2021
…ledger-cacti#685 Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Mar 22, 2021
…ledger-cacti#685 Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Mar 23, 2021
…ledger-cacti#685 Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Mar 26, 2021
…ledger-cacti#685 Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
to petermetz/cacti
that referenced
this issue
Mar 26, 2021
…ledger-cacti#685 Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
petermetz
added a commit
that referenced
this issue
Mar 26, 2021
Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes #685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
jordigiam
pushed a commit
to kikoncuo/cactus
that referenced
this issue
Apr 8, 2021
…ledger-cacti#685 Adds new parameters to the run transaction endpoint's request object that allow the caller to specify a the consistency strategy parameters that can define if the connector should wait for either: 1. the transaction to be confirmed only by the node's transaction pool 2. if at least the block containing the transaction should be mined by the ledger 3. an N number of additional blocks should be confirmed by the ledger in **addition** to the block that contained the transaction. The parameters also allow to specify a timeout in milliseconds that if unspecified defaults to the maximum safe integer that Javascript can represent which for practical purposes we consider to be the same as waiting until the heat death of the universe or infinity. Fixes hyperledger-cacti#685 Signed-off-by: Peter Somogyvari <peter.somogyvari@accenture.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Right now the transaction receipt that we return from the transaction runner endpoint is the local receipt of the node confirming the addition of the transaction to it's pool not the one that the ledger provides once the transaction has been added to a block for real.
The problem with that of course is that users will definitely want a way to have confirmation of the tx having gone through with the ledger, not just the tx pool.
Describe the solution you'd like
Need an optional parameter on the request body with a type of
"object"
that has members to describe how (if at all) Cactus should wait for the ledger confirmation. Should be able to express things such as:Describe alternatives you've considered
Nothing, I'm pretty sure we need this.
Additional context
This was suggested by Shingo and Takuma earlier so thanks to them for bringing it up as a possible improvement.
cc: @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo @jagpreetsinghsasan
The text was updated successfully, but these errors were encountered: