Skip to content

COM-231: Support worker set launch strategy in InvokeWorkersToRegisterTaskQueues #98

Merged
gcristea-temporal merged 1 commit into
mainfrom
COM-231
Jul 24, 2026
Merged

COM-231: Support worker set launch strategy in InvokeWorkersToRegisterTaskQueues #98
gcristea-temporal merged 1 commit into
mainfrom
COM-231

Conversation

@gcristea-temporal

@gcristea-temporal gcristea-temporal commented Jul 24, 2026

Copy link
Copy Markdown
Contributor

What was changed

Extended InvokeWorkersToRegisterTaskQueues to support computeprovider.LaunchStrategyWorkerSet.

Why?

WCI was not scaling up for Cloud Run, resulting in the task queue for the worker deployment version not being created.

Checklist

  1. Closes
    COM-231

@gcristea-temporal
gcristea-temporal requested a review from a team as a code owner July 24, 2026 17:08

@justinschoeff justinschoeff left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do we want to add tests in a follow-on, I don't see coverage in activities_test currently? We do have coverage for it in integ tests though.

// registerTaskQueueWorkerSetSize is the instance count a worker-set provider is
// scaled to so a single worker comes up and registers the task queue. The scaling
// algorithm resizes the set from there.
registerTaskQueueWorkerSetSize int32 = 1

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

should this be seeding to initial_count instead of 1?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Initial count may be 0

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ah you are correct, that is possible. I'm thinking through a scenario where the update to 1 goes unnoticed by the scaling logic when it reads the actual state as initial_count instead of 1 and skips performing a scaling action.

say a customer set it to initial_count, and we primed it down to 1. and the scaling algo thinks desired == current == initial_count and skips scaling action here

scaleBlockReason = "desired_equals_current"
. i may be overthinking but is that a concern?

@gcristea-temporal
gcristea-temporal merged commit b48b541 into main Jul 24, 2026
8 checks passed
@gcristea-temporal
gcristea-temporal deleted the COM-231 branch July 24, 2026 19:29
Comment on lines +282 to +287
case computeprovider.LaunchStrategyWorkerSet:
// Scale the set up so a worker comes up and registers the task queue.
if err := provider.UpdateWorkerSetSize(ctx, req.RequestContext, config, registerTaskQueueWorkerSetSize); err != nil {
recordError(wcimetrics.ErrorTypeComputeProviderFailed)
return temporal.NewApplicationErrorWithCause(fmt.Sprintf("%s: %s", k, err.Error()), "InvokeWorkerFailed", err)
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

with this approach, the scaling algorithm will misunderstand the current worker set size (and also this can break the existing worker pool if it already processes things).

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