-
Notifications
You must be signed in to change notification settings - Fork 911
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
Worker versioning - add BuildIDs search attribute #4284
Conversation
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.
The part adding the search attribute looks good to me.
"HistorySizeBytes": { | ||
"type": "long" | ||
}, | ||
"BuildIDs": { |
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.
Given that the other "ids" above are capitalized (WorkflowId
, RunId
), should it be better if this were BuildIds
?
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.
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.
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.
Here you are.
currResetPoints = ms.executionInfo.AutoResetPoints.Points | ||
} else { | ||
currResetPoints = make([]*workflowpb.ResetPointInfo, 0, 1) | ||
resetPoints := exeInfo.AutoResetPoints.Points |
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.
You're removing the check exeInfo.AutoResetPoints != nil
.
Is it possible for this to be nil
? If it it, this can cause a panic.
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.
It can't here because if we don't add a reset point the function returns early
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.
resetPoints := exeInfo.AutoResetPoints.Points | |
resetPoints := exeInfo.GetAutoResetPoints().GetPoints() |
is guaranteed to be safe.
"HistorySizeBytes": { | ||
"type": "long" | ||
}, | ||
"BuildIDs": { |
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.
"BuildIDs": { | |
"BuildIds": { |
if !request.UseVersioning { | ||
versionStamp = nil | ||
} | ||
// TODO: omit BinaryChecksum if version stamp is present and matches BinaryChecksum |
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.
can we/should we do anything about this? are we going to have these repeated twice in the event for now?
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.
Hmm... I think the worker will send both, let me track this and figure out what we want to do.
if !stamp.GetUseVersioning() { | ||
return taskQueue, nil | ||
} |
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.
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)
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.
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.
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.
Let's fix before we merge and this of course depends on your changes too.
tests/integrationbase.go
Outdated
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) | ||
} |
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.
use s.Eventually
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, wasn't aware of that.
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.
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 :-(.
Ended up renaming |
Note: This commit came from a feature branch and is not expected to build.
Note: This commit came from a feature branch and is not expected to build.
Note: This commit came from a feature branch and is not expected to build.
Note: This commit came from a feature branch and is not expected to build.
Part of #3303