CLI Feature: State management

[srinjoyc]

👋   If you are interested in working on this issue, please check out the Getting Started guide on HackerEarth!

Description (Problem Statement)

The CLI should allow saving the current state and then later restarting from that point similar to how you can use git to move between states. This feature is mostly implemented in the PR branch but should be tested, extended with a test suite, and ensure the UX is great.

Experience Required

• Experience with Go
• Basic understanding of Flow blockchain

Minimum Feature Set (Acceptance Criteria)

A developer has commands to achieve the following actions:

• saving the state under a name
• restoring to the named state
• deleting a state
• overwriting a state

The state should be persistent between restarts

Extension (Optional) Feature Set

Interoperability with the Emulator GUI task.

Milestone Requirements

1. Finish the implementation and making sure it works
2. Write tests around the feature proving the functionality of it
3. Documentation of the feature

Software Requirements

Maintainability

Code should be written with best practices in mind.

Testing

Tests should cover all the code implementing this functionality.

Other Requirements

Documentation

• All the commands and the usage should be well documented.

Code standards or guidelines

• Follow the general contribution guidelines.

Judging Criteria

• For all projects, technical & high-level judging criteria apply.

Resources

• General Resource Guide
• CLI
  • Repository
  • Design guidelines
• The issue
• Branch with feature mostly implemented

[devbugging]

Hi 👋
my name is Gregor, and as a software engineer working on developer tools, I will be your point of contact for this task, so good luck, and don't hesitate to reach out to me with any problems or questions.

I'll keep an eye on your progress and will be reviewing your code.

You can comment here or find me on Discord (I'm sideninja#1970). Join the Flow Discord server if you're not there already!

[bluesign]

Hey @sideninja ,

I would love to have this feature. I like the snapshot concept, but what would you think to extend this task a bit more to instead emulator to expose subset of git functionality, it would provide a git compatibility layer on storage.

When new block committed, commit to git state and use Block information, transaction status / events etc as git commit message.

Git is already providing log, tag, branch, remote origin etc support. Also as cli command same required functionality can be achieved. (just using git as underlying version controlling)

[devbugging]

Hey @sideninja ,

I would love to have this feature. I like the snapshot concept, but what would you think to extend this task a bit more to instead emulator to expose subset of git functionality, it would provide a git compatibility layer on storage.

When new block committed, commit to git state and use Block information, transaction status / events etc as git commit message.

Git is already providing log, tag, branch, remote origin etc support. Also as cli command same required functionality can be achieved. (just using git as underlying version controlling)

That's a very interesting idea.
Git could be even used as a go module in the emulator to provide this functionality.
It's a bit funny because the ledger itself has all the history but the storage layer doesn't provide an easy API for this so it probably makes sense to have this kind of "layer 2" solution.

[bluesign]

yeah I first tried on ledger side, but branching is a big problem there, moving on a single like is easy, when you try to branch things are getting a bit complicated.

But with git module it is almost supporting every git operation + cli can translate cli command to git commands too. Also log is pretty nice.

[bluesign]

Team: https://www.hackerearth.com/challenges/hackathon/flip-fest/dashboard/3744a70/team/
@bluesign (Tackling solo)
plan time: 2021-10-17

So I will work on this one, I would like to integrate also with onflow/cadence#1160 so we can have a command to use in testing to load, save and switch to some snapshot.

[psiemens]

@bluesign Awesome, you're approved 😄

[bluesign]

I managed to finish first part: integrating git to emulator, committing to git on transaction executions etc.

But stuck with integrating into cadence ( as discussed in onflow/cadence#1160 )

Actually I managed to integrate by creating a newScriptInvocator and replacing vm's ScriptProcessors. ( Technically switching state in transaction would not be possible anyway )

So far I manage to create a switchState cadence built-in method, and by executing script you can change emulator state ( switching to another branch in git )

But if someone from FVM side can give some light, maybe there is a better way to do this.

[devbugging]

I managed to finish first part: integrating git to emulator, committing to git on transaction executions etc.

But stuck with integrating into cadence ( as discussed in onflow/cadence#1160 )

Actually I managed to integrate by creating a newScriptInvocator and replacing vm's ScriptProcessors. ( Technically switching state in transaction would not be possible anyway )

So far I manage to create a switchState cadence built-in method, and by executing script you can change emulator state ( switching to another branch in git )

But if someone from FVM side can give some light, maybe there is a better way to do this.

Maybe @janezpodhostnik can help with FVM.

[bluesign]

Thanks, it would be the easiest I guess. Otherwise another option would require another RPC channel.

[janezpodhostnik]

@bluesign and I had a chat, and I've also done some thinking. Here are my notes.

Creating a new ScriptInvocator and replacing the vm's ScriptProcessors is the way to go currently, and is the best solution for now and I'm totally on board with it. The thing to note is that if the ScriptInvocator changes in FVM the new ScriptInvocator in the emulator also needs to be updated (but that does not happen often).

The suggestion was that the ScriptProcessors would be able to "pass on" the predeclared values to the next ScriptProcessor, that way there would be no need to redefine the ScriptInvocator but new ScriptProcessors could just be added earlier in the pipeline to define the cadence predeclared values, which the ScriptInvocator would then use. It's definitely an interesting suggestion, that I have to look into.

It might also help if there was the possibility to add global predeclared values to the context that are appended to each script/tx processor. I have to check if that would be helpful.

I am slightly worried that "operational", emulator specific, cadence functions are being added, as that might be confusing for user when they switch to/from the emulator. Namespacing these functions would definitely help, but maybe it might be worth considering having another communication channel to/from the emulator for these kind of functionalities.