Feature Discussion | Rerun last RPC

[Aman Garg]

Describe the feature

Post making an RPC, it'd be great if we could expose another tool in the REPL/CLI to repeat the last entered RPC using !! similar to BASH. Keep in mind, that regardless of the run status, there should be an option to repeat it.

Open to other interpretations such as

• evans :: repeatLast
• evans :: runLast
• evans :: !!
• evans:: repeat

Motivation

• Case in point: If the GRPC server is down during the time it takes to fill in the payload, the entire exercise need to be repeated in order to submit the failed RPC.
• Main motivation is to save developer time and productivity when dealing with larger payloads. Or to simply repeat and rerun against various server versions

Expected behaviour

• Run the last command with all of the previous inputs verbatim.
• RPC runs even if it was not successful the previous time.
• No user overrides against the input the command was fed the first time (at least in v1)
• When any new RPC is entered, the last run RPC pointer is updated.

What do you think about this? If this looks good, I can work towards a PR.

P.S Github automatically added the bug` label. Kindly remove it.

[ktr]

Thanks for your proposal.

Mostly looks great about use cases and expected behavior. However, we should consider some points even more carefully.

1. About CLI mode support

CLI mode accepts input from stdin or a file in its command line like bash. So, I think it's not needed to support command repetition. We can repeat the command with the bash's mechanism. It's easy to re-use input by redirecting input into a file in advance.

2. About the user interface

Does the proposed interface look like the following?

api.Example@127.0.0.1:50051> call Unary
name (TYPE_STRING) => foo
{
  "message": "foo"
}

api.Example@127.0.0.1:50051> !!
{
  "message": "foo"
}

In REPL mode, Evans has some commands such as call, describe. So, It's felt that it is unclear what repetition is.
How about implementing this feature in the call command?

For example,

api.Example@127.0.0.1:50051> call Unary
name (TYPE_STRING) => foo
{
  "message": "foo"
}

api.Example@127.0.0.1:50051> call -r
{
  "message": "foo"
}

Note that I used -r, a new option for ease of implementation, but I'm not hung up on it.

[Aman Garg]

About CLI mode support

I agree about the feature being more or less redundant in a CLI mode since the command can be easily the input from a file.

---

Does the proposed interface look like the following?

Yes, the proposed interface is exactly what you described.

---

How about implementing this feature in the call command?

I agree. The repeat really doesn't make sense for commands other than call.

• Since there exists no standard flag to rerun the last command (e.g -v is either version or verbose, mostly agreed upon), it makes sense to use -r here unless you have other features that might warrant a more natural fit to the -r flag like recurse etc.

• The idea is to be able to issue a quickfire repeat of the previous RPC while the user is in the REPL mode. Minimum keystrokes to repeat the last command would make the feature appealing to users. Hence call -r looks good to me.

[ktr]

The idea is to be able to issue a quickfire repeat of the previous RPC while the user is in the REPL mode. Minimum keystrokes to repeat the last command would make the feature appealing to users.

I agree with this idea.
The only concern is that it conflicts with -r, the short form of --reflection which is a global flag, but this feature is performed after REPL is invoked from the command line (in other words after issuing a command with --reflection), so users may not be confused.

# CLI mode
$ evans -r cli ...
...

# REPL mode
$ evans -r repl
api.Example@127.0.0.1:50051> call Unary
name (TYPE_STRING) => foo
{
  "message": "foo"
}

api.Example@127.0.0.1:50051> call -r
{
  "message": "foo"
}

---

I think that call -r looks good to me.
If you have no other concerns, would you toward to work on the implementation?

[Aman Garg]

Sounds good. Yes, I'll work on it.