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
- Read ErrRegister's embedded message — it contains the server's explanation — and fix the underlying deployment/task queue issue it names.
- Upgrade the SDK/client so newer typed failure kinds are translated instead of falling into the generic ErrRegister branch.
- Verify worker deployment name, version, and task queue names match an existing valid deployment registration.
- 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, ®Err) {
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, ®Err) {
// server rejected registration; inspect regErr.Error()
} Try / catch
err := client.RegisterTaskQueueWorker(ctx, req)
if err != nil {
var regErr workerdeployment.ErrRegister
if errors.As(err, ®Err) {
logger.Error("registration rejected", "msg", regErr.Error())
} else {
// transport error: may be retryable
return err
}
} Prevention
- Read the wrapped server message before retrying
- Keep client and server versions aligned so typed failures are translated
- Verify deployment name/version and task queue names before registration
- Treat ErrRegister as non-retryable until its cause is fixed
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
- %w: state namespace failover version < ref namespace failove
- %w: state namespace failover version > ref namespace failove
- %w: state transition count < ref transition count: %v < %v
- version cannot be nil on start
- failed to read version demotion signal configuration: %w
AI-assisted analysis of temporalio/temporal@bde624efd1 (2026-09-01).
Data as JSON: /api/errors/df51763bc91d32f9.
Report an issue: GitHub.