temporalio/temporal · error · ErrRegister

${failure.Message}

Error message

${failure.Message}

What it means

In the worker deployment (versioning) client, handleRegisterVersionFailures translates a failed RegisterVersion outcome into a Go error. For unrecognized application-failure types it wraps failure.Message in ErrRegister. The message text itself comes from the server, so this error surfaces whatever the history/frontend service rejected the registration with.

Source

Thrown at service/worker/workerdeployment/client.go:393

	// starting and updating the deployment version workflow, which in turn starts a deployment workflow.
	outcome, err := d.updateWithStartWorkerDeployment(ctx, namespaceEntry, deploymentName, &updatepb.Request{
		Input: &updatepb.Input{Name: RegisterWorkerInWorkerDeployment, Args: updatePayload},
		Meta:  &updatepb.Meta{UpdateId: requestID, Identity: identity},
	}, identity, requestID, d.getSyncBatchSize())
	if err != nil {
		return err
	}
	return d.handleRegisterVersionFailures(outcome)
}

func (d *ClientImpl) handleRegisterVersionFailures(outcome *updatepb.Outcome) error {
	if failure := outcome.GetFailure(); failure.GetApplicationFailureInfo().GetType() == errMaxTaskQueuesInVersionType ||
		failure.GetApplicationFailureInfo().GetType() == errTooManyVersions {
		return newResourceExhaustedError(failure.GetMessage())
	} else if failure.GetApplicationFailureInfo().GetType() == errNoChangeType {
		return nil
	} else if failure != nil {
		return ErrRegister{error: errors.New(failure.Message)}
	}
	return nil
}

func newResourceExhaustedError(message string) *serviceerror.ResourceExhausted {
	return &serviceerror.ResourceExhausted{
		Message: message,
		Scope:   enumspb.RESOURCE_EXHAUSTED_SCOPE_NAMESPACE,
		Cause:   enumspb.RESOURCE_EXHAUSTED_CAUSE_WORKER_DEPLOYMENT_LIMITS,
	}
}

func (d *ClientImpl) handleUpdateVersionFailures(outcome *updatepb.Outcome, deploymentName, buildID string) error {
	if failure := outcome.GetFailure(); failure.GetApplicationFailureInfo().GetType() == errVersionNotFound {
		return serviceerror.NewNotFoundf(ErrWorkerDeploymentVersionNotFound, buildID, deploymentName)
	} else if failure.GetApplicationFailureInfo().GetType() == errFailedPrecondition {
		return serviceerror.NewFailedPrecondition(failure.Message)
	} else if failure != nil {

View on GitHub (pinned to bde624efd1)

Solutions

  1. Read ErrRegister's embedded message — it contains the server's explanation — and fix the underlying deployment/task queue issue it names.
  2. Upgrade the SDK/client so newer typed failure kinds are translated instead of falling into the generic ErrRegister branch.
  3. Verify worker deployment name, version, and task queue names match an existing valid deployment registration.
  4. Retry registration only after fixing the cause; ErrRegister wraps a plain error, not a retryable one, so blind retries fail identically.

Example fix

// before
err := client.RegisterTaskQueueWorker(ctx, req) // returns ErrRegister{...}
log.Fatal(err)
// after
var regErr workerdeployment.ErrRegister
if errors.As(err, &regErr) {
    logger.Error("worker version registration rejected by server", "reason", regErr.Error())
    return regErr
}
Defensive patterns

Strategy: try-catch

Type guard

var regErr workerdeployment.ErrRegister
if errors.As(err, &regErr) {
    // server rejected registration; inspect regErr.Error()
}

Try / catch

err := client.RegisterTaskQueueWorker(ctx, req)
if err != nil {
    var regErr workerdeployment.ErrRegister
    if errors.As(err, &regErr) {
        logger.Error("registration rejected", "msg", regErr.Error())
    } else {
        // transport error: may be retryable
        return err
    }
}

Prevention

When it happens

Trigger: RegisterTaskQueueWorker, SetCurrentVersion, or SetRampingVersion completes and the response outcome carries an ApplicationFailureInfo whose type is not errMaxTaskQueuesInVersionType, errTooManyVersions, or errNoChangeType — i.e. any other server-side registration failure.

Common situations: Worker deployment versions exceeding limits in forms not covered by the typed errors; task queue/partition lookup failures server-side; mismatched worker build IDs or deployment names; server version older/newer than client expectations so new failure types fall into the generic branch.

Related errors


AI-assisted analysis of temporalio/temporal@bde624efd1 (2026-09-01). Data as JSON: /api/errors/df51763bc91d32f9. Report an issue: GitHub.