-
Notifications
You must be signed in to change notification settings - Fork 3
Time travel test #377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Time travel test #377
Conversation
tillrohrmann
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating an e2e test for the time travel functionality. The changes look good to me. I left a few clarifying questions for my own understanding. +1 for merging once the feature lands.
| .containsExactlyInAnyOrder( | ||
| "Command: Input", | ||
| "Command: Call", | ||
| "Notification: CallInvocationId", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my own understanding: When are we returning from val firstMethodResponse = TimeTravelTestCalleeServiceClient.fromContext(ctx).firstMethod()? Before or after the invocation id was decided?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
before, getting the invocation id is an async operation
| "Notification: Run", | ||
| "Command: Call", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my own understanding: The notification is allowed to move past Command: Call, right? Is it generated once the run closure completes and persists the value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, that's why containsExactlyInAnyOrder
| // Set shouldFail to false so the handler will succeed after time travel | ||
| TimeObject.shouldFail.set(false) | ||
|
|
||
| // Use the time travel API to trim entry index 2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We seem to trim trimIndex and not a fixed index 2.
| "Command: SetState", | ||
| "Command: Run", | ||
| "Notification: Run", | ||
| "Command: Call", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my own understanding: Will the SDK send the commands in creation order (as the awaitables are created in the code)? I would assume so because otherwise it's probably hard to match them on replay with existing journal entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will the SDK send the commands in creation order
yes but the notification order is established by the runtime
No description provided.