How smart can grpc-replay be when inferring dynamic/ID fields?

[bradleyjkemp]

Related: #1

A very common flow is for the client to send a Create request and receive in response some sort of handle that they can later use to Read/Update/Delete the resource they just created.
It would be really nice if grpc-replay could infer these fields and dynamically substitute them into later requests.

Detection process:

• If a value is returned in a response that is later used in a request
• The value is of type string (anything else?)
• The value is the only field that differs between the actual response and the dump response

Where we are certain a field is an ID we can substitute immediately. When unsure, can prompt the user to tell us if we should treat the field as an ID.

A command-line flag would be useful to force fields to be treated as IDs.

Questions:

• Under what conditions are we certain that something is an ID?
• Is it ok to re-try a request if we change our mind about whether something is an ID? (would want to at least inform the user and likely prompt them whether or not to continue)
• What information do we need to prompt the user for them to be able to decide if something is an ID

[bradleyjkemp]

I think we can solve this to start with by allowing the use of "variables" within replays: if a variable appears in the expected server response then it gets assigned to and the same value will be sent if the variable later appears in a client message.