feat(async-flow): startGeneration: a new synthetic LogEntry

[michaelfig]

closes: #9384

Description

This pull request introduces a startGeneration log entry to capture the generation (restart) number for subsequent log entries. The most important changes are grouped below by theme.

Log Entry Enhancements:

• Introduced startGeneration and updated LogEntryShape to include a new log entry type for starting a generation (packages/async-flow/src/type-guards.js).

Log Store Improvements:

• Retrieve the current generation number from a zone.mapStore and use it in LogStore ephemera to track its generation (packages/async-flow/src/log-store.js).
• Modified prepareLogStore to define a predicate for filtering log entries, and added methods for retrieving unfiltered log entries (packages/async-flow/src/log-store.js).
• Updated test cases to validate the new generation number and unfiltered log entries (packages/async-flow/test/log-store.test.js).

Replay Membrane Adjustments:

• Added support for startGeneration in the replay membrane to handle generation-specific operations (packages/async-flow/src/replay-membrane.js).

Type Definitions:

• Updated LogEntry and FutureLogEntry types to include the new generation entry type (packages/async-flow/src/types.ts).

Security Considerations

n/a

Scaling Considerations

Low overhead implementation.

Documentation Considerations

Not necessary yet, just laying groundwork for the infrastructure so that a future change can use it to implement asyncFlow versioning.

Testing Considerations

Some new *Unfiltered methods of the LogStore now have some tests.

Upgrade Considerations

Designed to enable future upgrade of async flows.

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	9b3a3d1
Status:	✅  Deploy successful!
Preview URL:	https://53341ddd.agoric-sdk.pages.dev
Branch Preview URL:	https://mfig-9384-log-store-generati.agoric-sdk.pages.dev

View logs

[mhofman]

I think I'd like to see a test of both a log reset and a flow restart that shows the generation of an invocation getting bumped when inserting new log entries. This likely can be done using explicit reset/restarts, and without a simulated liveslots upgrade (especially because I haven't landed the liveslots test framework improvements yet, and we don't have testing hooks to peek into the state of async flow, which would possibly be covered by #9753)

[erights]

All my issues are dealt with well, so approving to remove my blockage. But you should still iterate with @mhofman to his satisfaction before merging.

[mhofman]

LGTM (once the test snapshots are updated to reflect the new 0 based generation)

[mhofman]

I am wondering if we should include a lastGenerationPush or something like that in the state of the log store, and some assertion that the start generation never regresses (it can stay the same).

[michaelfig]

I am wondering if we should include a lastGenerationPush or something like that in the state of the log store, and some assertion that the start generation never regresses (it can stay the same).

I appreciate the need to have guarantees like this, but adding extra code for validation didn't strike me as the best thing to do. Ruminating on it, I'd prefer to encapsulate the generation number within prepareLogStore (where its increment-only behaviour would be easily verifiable by inspection) rather than passing it in from outside.

[mhofman]

I'd prefer to encapsulate the generation number within prepareLogStore (where its increment-only behaviour would be easily verifiable by inspection) rather than passing it in from outside.

Yeah I think that's what was making me uneasy, that async-flow could mistakenly not pass the right generation. I prefer it container like this much better.