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

Worker versioning - add BuildIDs search attribute #4284

Conversation

bergundy
Copy link
Member

@bergundy bergundy commented May 5, 2023

Part of #3303

@bergundy bergundy requested a review from a team as a code owner May 5, 2023 04:43
@bergundy bergundy requested review from rodrigozhou and alexshtin May 5, 2023 04:44
Copy link
Contributor

@rodrigozhou rodrigozhou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The part adding the search attribute looks good to me.

"HistorySizeBytes": {
"type": "long"
},
"BuildIDs": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the other "ids" above are capitalized (WorkflowId, RunId), should it be better if this were BuildIds?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I thought about that but because it's plural I think it'd be clearer if IDs stands out more.
I'm now not so convinced.
I'll get another opinion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here you are.

currResetPoints = ms.executionInfo.AutoResetPoints.Points
} else {
currResetPoints = make([]*workflowpb.ResetPointInfo, 0, 1)
resetPoints := exeInfo.AutoResetPoints.Points
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're removing the check exeInfo.AutoResetPoints != nil.
Is it possible for this to be nil? If it it, this can cause a panic.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can't here because if we don't add a reset point the function returns early

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
resetPoints := exeInfo.AutoResetPoints.Points
resetPoints := exeInfo.GetAutoResetPoints().GetPoints()

is guaranteed to be safe.

"HistorySizeBytes": {
"type": "long"
},
"BuildIDs": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"BuildIDs": {
"BuildIds": {

if !request.UseVersioning {
versionStamp = nil
}
// TODO: omit BinaryChecksum if version stamp is present and matches BinaryChecksum
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we/should we do anything about this? are we going to have these repeated twice in the event for now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I think the worker will send both, let me track this and figure out what we want to do.

Comment on lines +1188 to +1190
if !stamp.GetUseVersioning() {
return taskQueue, nil
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't do this here, instead, leave the build stamp out of the AddWorkflowTaskRequest on the history side (there's no reason for matching to know about it if it's not going to use it)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'll need to to not send the stamp directly from history as I mentioned in my review of your last PR.
For now I'm leaving this on so the tests pass.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's fix before we merge and this of course depends on your changes too.

Comment on lines 363 to 377
func (s *IntegrationBase) retry(attempts int, interval time.Duration, fn func() error) {
var lastErr error
for attempt := 1; attempt <= attempts; attempt++ {
lastErr = fn()
if lastErr == nil {
return
}
time.Sleep(interval)
}
s.FailNow(fmt.Sprintf("%v after %v attempts", lastErr, attempts))
}

func (s *IntegrationBase) retryReasonably(fn func() error) {
s.retry(30, 500*time.Millisecond, fn)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use s.Eventually

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, wasn't aware of that.

Copy link
Member

@alexshtin alexshtin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I do insist on BuildIDs to BuildIds rename everywhere besides go code. I personally would do it everywhere in go code too, but because of old go linter (which we don't currently use) all our Id are ID in go :-(.

@bergundy
Copy link
Member Author

bergundy commented May 8, 2023

Ended up renaming BuildID to BuildId in the entire code base.
I'll address some of the open comments in a follow up PR.

@bergundy bergundy merged commit c74fb6d into temporalio:worker-versioning May 8, 2023
@bergundy bergundy deleted the worker-versioning-build-id-search-attribute branch May 8, 2023 23:38
dnr pushed a commit that referenced this pull request May 26, 2023
Note: This commit came from a feature branch and is not expected to build.
dnr pushed a commit to dnr/temporal that referenced this pull request May 26, 2023
Note: This commit came from a feature branch and is not expected to build.
dnr pushed a commit that referenced this pull request May 26, 2023
Note: This commit came from a feature branch and is not expected to build.
dnr pushed a commit that referenced this pull request May 26, 2023
Note: This commit came from a feature branch and is not expected to build.
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.

4 participants