[programmability] processing logic for module publishing #59
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sblackshear
requested review from
huitseeker,
lxfind,
patrickkuo,
gdanezis and
oxade
gdanezis
approved these changes
Dec 15, 2021
|
|
||
| // Order-specific logic | ||
| // | ||
| // TODO: think very carefully what to do in case we throw an Err here. | ||
| match &order.kind { | ||
| let outputs = match order.kind { |
There was a problem hiding this comment.
Sadly I think we modified the same section in 'handle_confirmation_order'. I think that the abstraction that records the outputs and deletions is now complete in #62 and you should be able to use it as it is. Right?
There was a problem hiding this comment.
Yep, your fix is much more general. I will use it.
| @@ -234,23 +237,31 @@ impl Authority for AuthorityState { | |||
| Some(c.gas_budget), | |||
| ) | |||
| .map_err(|_| FastPayError::MoveExecutionFailure)?; | |||
| // TODO: return output objects here | |||
| Vec::new() | |||
There was a problem hiding this comment.
Ok, PR #62 takes care of this.
| // Note: State is mutated below and should be committed in an atomic way | ||
| // to memory or persistent storage. Currently this is done in memory | ||
| // through the calls to store being infallible. | ||
| outputs |
There was a problem hiding this comment.
Here if you just to a 'write' to the temporary store (see #62 ) I think it works.
| @@ -260,6 +271,7 @@ impl Authority for AuthorityState { | |||
|
|
|||
| // Add new object, init locks and remove old ones | |||
| self.insert_object(output_object); | |||
| // TODO: no need to init order locks for immutable outputs | |||
There was a problem hiding this comment.
Let me address this in PR #62 .
Filling out the logic for processing a module publish message. This will allow us to define a fastX genesis transaction containing an initial set of modules, which we need for testing anything with programmability. This is a bit rough (see the many inline TODO's/tasks), but an important step toward getting a system w/ programmability working end-to-end! - Added the `TxContext` type, which knows how to generate globally unique ID's from the digest of the current transaction. - Add `adapter::publish`, which deserializes/verifies a set of input modules, generates fresh object ID's for them, and returns fastX objects containing each module - Filled out the authority code path that handles a module publish message, did some refactoring to make sure the modules get persisted as output objects - Added an end-to-end test demonstrating successful publishing of a module.
sblackshear
force-pushed
the
publish_message
branch
from
b9a2f32 to
17482e8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Filling out the logic for processing a module publish message. This will allow us to define a fastX genesis transaction containing an initial set of modules, which we need for testing anything with programmability.
This is a bit rough (see the many inline TODO's/tasks), but an important step toward getting a system w/ programmability working end-to-end!
TxContexttype, which knows how to generate globally unique ID's from the digest of the current transaction.adapter::publish, which deserializes/verifies a set of input modules, generates fresh object ID's for them, and returns fastX objects containing each module