async-flow: need incarnation number in the log classifying entries

[erights]

Another thing that must happen before we commit to durable log state.

[mhofman]

We need to decide on the design for the "incarnation number", and probably need to pick a different name. The contract code does not know the "incarnation number" of the vat. This problem is similar to the state migration of durable kinds (#7407).

While asyncFlow could maintain an internal "incarnation number" for the flow, the reality is that most vat upgrades or restarts will not require any changes to the flow's guest logic. As such, a version number maintained by the author may be preferable. However that runs the risk that the author does not realize they made a replay incompatible change, deploys the update, which now has replays of old logic failing (triggered late because replays are not eager), and new invocations using the new logic. In that case we'd still want the author to have a way out of this, so maybe we need both a "flow incarnation number" automatically maintained by async-flow, and a "flow version number" explicitly provided by the author (and maybe simply used as a mapping to flow incarnation numbers)

[michaelfig]

After further discussion with @mhofman and @kriskowal, I understand that the minimal change needed is to have an invocation of prepareAsyncFlowTools increment a flowGeneration counter in its outerZone and make it part of each log entry created by the flows that are defined by that instance of the tools.

[erights]

Or you could add a new instruction that declares a new generation number starting with the ops that come immediately after it.

[michaelfig]

Or you could add a new instruction that declares a new generation number starting with the ops that come immediately after it.

I did suggest this, but @mhofman was against it (though I don't remember what the objection was). Mathieu, can you recap your objections in this thread?

[mhofman]

From what I understand, @erights is suggesting that we record the change in flowGeneration by using a synthetic entry in the log instead of recording the current generation as an extra element for every log entry. I don't remember discussing this explicitly, and no objections comes to mind right now.

[michaelfig]

@mhofman summarised what I also understood of @erights' suggestion:

record the change in flowGeneration by using a synthetic entry in the log instead of recording the current generation as an extra element for every log entry.

And then added:

I don't remember discussing this explicitly, and no [objection] comes to mind right now.

Ah. Maybe I didn't voice it clearly enough, or it didn't actually get out of my head into our conversation. :)

@eright's suggestion is certainly a much less intrusive change than adding metadata to every single log entry, so I'll pivot my approach to use it instead.