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
- Pass a duration with a unit: 30s, 500ms, 1m, 2h.
- Check the flag value in your script/env for typos or empty interpolation.
- If unset is desired, remove the flag entirely rather than passing an empty/invalid string.
- 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
- Always include a time unit in duration flags (500ms, 30s).
- Validate duration env/config values at startup with time.ParseDuration.
- Avoid bare numbers in scripts; quote and unit-suffix interpolated values.
- Centralize duration parsing in one helper with clear errors.
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.
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
- Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.
Related errors
- failed to parse client_pool_ttl: %v
- failed to parse client_pool_close_timeout: %v
- Cannot use two forms of the same flag: <name> <ff.Name>
- flags not parsed
- agent: ResumeStreamAsk requires a checkpoint
AI-assisted analysis of micro/go-micro@24529f1404 (2026-09-01).
Data as JSON: /api/errors/3f97440b744c2d8a.
Report an issue: GitHub.