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

Reduce SA bloat on GetVersion #1056

Merged

Conversation

Quinn-With-Two-Ns
Copy link
Contributor

Reduce SA bloat on GetVersion. This PR implements 3 new features to the Go SDK.

  1. Adds capability visibility to workflow and activity task execution.
  2. Adds sdk flags based off the core API to allow internal SDK versioning
  3. Uses sdk flags to no longer upsert search attributes on GetVersion if that search attribute would exceed the default size limit

@Quinn-With-Two-Ns Quinn-With-Two-Ns marked this pull request as ready for review March 8, 2023 01:16
@Quinn-With-Two-Ns Quinn-With-Two-Ns requested a review from a team as a code owner March 8, 2023 01:16
@Quinn-With-Two-Ns
Copy link
Contributor Author

resolves: #1052

// Server has a limit for the max size of a single search attribute value. If we exceed the default limit
// do not try to upsert as it will cause the workflow to fail.
updateSearchAttribute := true
if wc.sdkFlags.tryUse(LimitChangeVersionSASize, !wc.isReplay) && len(attr.IndexedFields[TemporalChangeVersion].GetData()) >= changeVersionSearchAttrSizeLimit {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll note this will change the behavior for new WFT not new workflows

internal/internal_command_state_machine.go Outdated Show resolved Hide resolved
internal/internal_event_handlers.go Show resolved Hide resolved
internal/internal_event_handlers.go Show resolved Hide resolved
internal/internal_flags.go Outdated Show resolved Hide resolved
internal/internal_flags.go Outdated Show resolved Hide resolved
internal/internal_flags.go Show resolved Hide resolved
internal/internal_task_handlers.go Outdated Show resolved Hide resolved
internal/internal_event_handlers.go Outdated Show resolved Hide resolved
Copy link
Member

@cretz cretz 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 would like either @Sushisource or @bergundy to review the SDK flag behavior just in case.

Copy link
Member

@Sushisource Sushisource left a comment

Choose a reason for hiding this comment

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

Looking good

internal/internal_flags.go Outdated Show resolved Hide resolved
Comment on lines +241 to +242
// If a flag is not recognized (value is too high or not defined), it must fail the workflow task
return false, "", nil, errors.New("could not recognize SDK flag")
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, I'm actually not doing this currently and probably should.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh that reminds me I wanted to add a test for this case, I'll do that quickly

Comment on lines 287 to +288
// TODO(maxim): Refactor to return a struct instead of multiple parameters
func (eh *history) NextCommandEvents() (result []*historypb.HistoryEvent, markers []*historypb.HistoryEvent, binaryChecksum string, err error) {
func (eh *history) NextCommandEvents() (result []*historypb.HistoryEvent, markers []*historypb.HistoryEvent, binaryChecksum string, sdkFlags []sdkFlag, err error) {
Copy link
Member

Choose a reason for hiding this comment

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

Might be a good time to do this TODO

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did try this and didn't find it to much cleaner because this code uses named return values heavily

@Quinn-With-Two-Ns Quinn-With-Two-Ns merged commit e047c84 into temporalio:master Mar 9, 2023
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.

3 participants