apache/beam · error

presultErr.Error()

Error message

presultErr.Error()

What it means

After waiting for a job to finish on a universal (remote) runner, Execute builds the final pipeline result. If constructing that result fails (presultErr != nil) while the earlier WaitForCompletion call also produced an error, the code returns the original error wrapped with the result-construction error's text via errors.Wrap(err, presultErr.Error()).

Source

Thrown at sdks/go/pkg/beam/runners/universal/runnerlib/execute.go:114

	jobID, err := Submit(ctx, client, prepID, token)
	if err != nil {
		return presult, err
	}

	log.Infof(ctx, "Submitted job: %v", jobID)

	// (4) Wait for completion.

	if async {
		return presult, nil
	}
	err = WaitForCompletion(ctx, client, jobID)

	res, presultErr := newUniversalPipelineResult(ctx, jobID, client, p)
	if presultErr != nil {
		if err != nil {
			return presult, errors.Wrap(err, presultErr.Error())
		}
		return presult, presultErr
	}
	return res, err
}

// UpdateGoEnvironmentWorker sets the worker artifact payload in
// the default environment.
func UpdateGoEnvironmentWorker(worker string, p *pipepb.Pipeline) error {
	fd, err := os.Open(worker)
	if err != nil {
		return err
	}
	defer fd.Close()

	sha256W := sha256.New()
	n, err := io.Copy(sha256W, fd)
	if err != nil {

View on GitHub (pinned to 12126d8942)

Solutions

  1. Read the outer error (from WaitForCompletion) first; it describes why the job failed.
  2. Check the wrapped presultErr text for the secondary metrics-fetch problem and verify runner connectivity.
  3. Inspect job logs via the runner's UI/CLI for the root failure cause.
  4. Retry submission once the runner service is healthy.
Defensive patterns

Strategy: try-catch

Try / catch

res, err := beam.Run(ctx, runner, p)
if err != nil {
    var wrapped interface{ Unwrap() error }
    if errors.As(err, &wrapped) { log.Printf("outer job error: %v; inner: %v", err, wrapped) }
    // prioritize the outer error describing the job failure
}

Prevention

When it happens

Trigger: Execute on a pipeline: WaitForCompletion returns an error AND newUniversalPipelineResult also fails (e.g. metrics fetch failed); the combined errors are returned wrapped.

Common situations: Remote job failed and its metrics endpoint is also unreachable/unavailable, so both error paths fire at once — typically during runner outages or jobs cancelled server-side.

Related errors


AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/8de7435669ce7135. Report an issue: GitHub.