Skip to content
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

Remove history truncation #1656

Conversation

Quinn-With-Two-Ns
Copy link
Contributor

Remove history truncation. As far back in the Go SDK as I can find we have this code to try to truncate any events past atWorkflowTaskCompletedEventID. It is not clear what the point of this code is and it has a number of bugs. Some of the issues are:

  • It can panic if h.Events[0].GetEventId() > atWorkflowTaskCompletedEventID
  • It is trying to check if the last event in history after truncation is a EVENT_TYPE_WORKFLOW_TASK_COMPLETED, but atWorkflowTaskCompletedEventID is from the workflow tasks GetStartedEventId so it should be a EVENT_TYPE_WORKFLOW_TASK_STARTED.
  • If history does go beyond GetStartedEventId then that indicated this workflow task is stale and will be rejected by the server anyway

Note: The cadence team also pointed out the strangeness of this code https://github.com/uber-go/cadence-client/blob/4d4c09f5053b53caea43100e170c327058731f5c/internal/internal_task_pollers.go#L961

@Quinn-With-Two-Ns Quinn-With-Two-Ns requested a review from a team as a code owner October 2, 2024 22:22
@cretz
Copy link
Member

cretz commented Oct 3, 2024

If history does go beyond GetStartedEventId then that indicated this workflow task is stale and will be rejected by the server anyway

What if there is a signal sent between when we first got partial history from PollWorkflowTaskQueueResponse and started iterating to get the rest? Wouldn't then the signal be past the last task completed we expected? I wonder if this can be somehow tested by having a history too large to fit in PollWorkflowTaskQueueResponse.history and have first history page iteration RPC be held up, then send a signal, then let history iteration continue.

@Quinn-With-Two-Ns
Copy link
Contributor Author

Wouldn't then the signal be past the last task completed we expected

When we are processing a new workflow task we never expect any event past the last workflow task started event because the server will buffer the signal

@cretz
Copy link
Member

cretz commented Oct 3, 2024

When we are processing a new workflow task we never expect any event past the last workflow task started event because the server will buffer the signal

👍 So to confirm, server guarantees that if a worker is processing a task, and that task is still valid, fetching history will never contain any events after the task being processed? (unsure if we need to check with them for some strange replication case or something)

@Quinn-With-Two-Ns
Copy link
Contributor Author

Server buffers events during a workflow task , this is a important behaviour all SDKs rely on while replaying history.

@Quinn-With-Two-Ns Quinn-With-Two-Ns force-pushed the remove-histroy-truncation branch from abe2471 to 65979bb Compare October 3, 2024 18:31
@Quinn-With-Two-Ns Quinn-With-Two-Ns force-pushed the remove-histroy-truncation branch from 65979bb to 55d845c Compare October 3, 2024 19:32
@Quinn-With-Two-Ns Quinn-With-Two-Ns merged commit cdd3070 into temporalio:master Oct 3, 2024
13 checks passed
ReyOrtiz pushed a commit to ReyOrtiz/temporal-sdk-go that referenced this pull request Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants