micro/go-micro · error

failed to parse client_request_timeout: %v

Error message

failed to parse client_request_timeout: %v

What it means

This error is returned by the CLI flag-parsing code in cmd/cmd.go when the value passed to the --client_request_timeout flag cannot be parsed by time.ParseDuration. The framework wraps client configuration options and fails fast before any request is made, so the client is never constructed with an invalid timeout. Note the message prints the raw string value, not the parse error itself.

Source

Thrown at cmd/cmd.go:633

	}

	if ttl := time.Duration(ctx.Int("register_ttl")); ttl >= 0 {
		serverOpts = append(serverOpts, server.RegisterTTL(ttl*time.Second))
	}

	if val := time.Duration(ctx.Int("register_interval")); val >= 0 {
		serverOpts = append(serverOpts, server.RegisterInterval(val*time.Second))
	}

	// client opts
	if r := ctx.Int("client_retries"); r >= 0 {
		clientOpts = append(clientOpts, client.Retries(r))
	}

	if t := ctx.String("client_request_timeout"); len(t) > 0 {
		d, err := time.ParseDuration(t)
		if err != nil {
			return fmt.Errorf("failed to parse client_request_timeout: %v", t)
		}
		clientOpts = append(clientOpts, client.RequestTimeout(d))
	}

	if r := ctx.Int("client_pool_size"); r > 0 {
		clientOpts = append(clientOpts, client.PoolSize(r))
	}

	if t := ctx.String("client_pool_ttl"); len(t) > 0 {
		d, err := time.ParseDuration(t)
		if err != nil {
			return fmt.Errorf("failed to parse client_pool_ttl: %v", t)
		}
		clientOpts = append(clientOpts, client.PoolTTL(d))
	}

	if t := ctx.String("client_pool_close_timeout"); len(t) > 0 {
		d, err := time.ParseDuration(t)

View on GitHub (pinned to 24529f1404)

Solutions

  1. Pass a duration with a unit: 30s, 500ms, 1m, 2h.
  2. Check the flag value in your script/env for typos or empty interpolation.
  3. If unset is desired, remove the flag entirely rather than passing an empty/invalid string.
  4. If the value comes from a config file, validate it with time.ParseDuration before launching.

Example fix

// before
./server --client_request_timeout 500
// after
./server --client_request_timeout 500ms
Defensive patterns

Strategy: validation

Validate before calling

func validDuration(s string) bool { _, err := time.ParseDuration(s); return err == nil }
if !validDuration(flagValue) { return fmt.Errorf("--client_request_timeout must be a Go duration like 500ms, got %q", flagValue) }

Try / catch

if _, err := time.ParseDuration(t); err != nil { return fmt.Errorf("invalid client_request_timeout %q: %v", t, err) }

Prevention

When it happens

Trigger: Running the binary with --client_request_timeout set to a string that is not a valid Go duration, e.g. --client_request_timeout 500 (missing unit) or --client_request_timeout 5sec (unsupported unit).

Common situations: Users copying timeout values from config files written in seconds/milliseconds ('500ms' works but '0.5' does not); CI scripts interpolating empty or unquoted values; mixing formats like '30s' vs '30'.

Understand the failure class

Background: "invalid duration" / "failed to parse duration": why your timeout, interval, or TTL string is rejected and which formats each library accepts — this error's family across 32 libraries.

Related errors


AI-assisted analysis of micro/go-micro@24529f1404 (2026-09-01). Data as JSON: /api/errors/3f97440b744c2d8a. Report an issue: GitHub.