What causes "rpc client: call failed: " in geektutu/7days-golang?

Raise the context timeout budget to cover dialing plus handler execution

rpc client: call failed:

Error message

rpc client: call failed:

What it means

Same mechanism as the day4 version: Client.Call runs the call asynchronously via Go and selects on the caller's context Done channel. If the context is cancelled or its deadline elapses before the response arrives, Call removes the pending call and returns "rpc client: call failed: " + ctx.Err(). This is the library's way of honoring context timeouts and cancellation.

Source

Thrown at gee-rpc/day5-http-debug/client.go:191

	}
	call := &Call{
		ServiceMethod: serviceMethod,
		Args:          args,
		Reply:         reply,
		Done:          done,
	}
	client.send(call)
	return call
}

// Call invokes the named function, waits for it to complete,
// and returns its error status.
func (client *Client) Call(ctx context.Context, serviceMethod string, args, reply interface{}) error {
	call := client.Go(serviceMethod, args, reply, make(chan *Call, 1))
	select {
	case <-ctx.Done():
		client.removeCall(call.Seq)
		return errors.New("rpc client: call failed: " + ctx.Err().Error())
	case call := <-call.Done:
		return call.Error
	}
}

func parseOptions(opts ...*Option) (*Option, error) {
	// if opts is nil or pass nil as parameter
	if len(opts) == 0 || opts[0] == nil {
		return DefaultOption, nil
	}
	if len(opts) != 1 {
		return nil, errors.New("number of options is more than 1")
	}
	opt := opts[0]
	opt.MagicNumber = DefaultOption.MagicNumber
	if opt.CodecType == "" {
		opt.CodecType = DefaultOption.CodecType
	}

View on GitHub (pinned to cf36443821)

Solutions

Raise the context timeout budget to cover dialing plus handler execution
Profile/fix slow server handlers or move heavy work out of the RPC path
Distinguish deadline-exceeded from cancellation (check ctx.Err() type or error string) and retry only on deadline exceeded with backoff
Pass a longer-lived context if the operation legitimately needs more time

Example fix

// before
ctx, _ := context.WithTimeout(context.Background(), 50*time.Millisecond)
err := client.Call(ctx, "Foo.Sum", args, reply) // deadline exceeded

// after
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
err := client.Call(ctx, "Foo.Sum", args, reply)

Defensive patterns

Strategy: try-catch

Validate before calling

if deadline, ok := ctx.Deadline(); ok && time.Until(deadline) < time.Second {
	return fmt.Errorf("insufficient timeout: %v", time.Until(deadline))
}

Try / catch

err := client.Call(ctx, "Foo.Sum", args, reply)
if err != nil {
	if errors.Is(ctx.Err(), context.DeadlineExceeded) {
		// retry with backoff on a new context budget
	} else if errors.Is(ctx.Err(), context.Canceled) {
		// caller aborted; do not retry
	}
}

Prevention

Budget timeouts to include dial, serialize, network and server time
Propagate and log ctx.Err() alongside the RPC error for diagnosis
Use per-method timeout tiers (fast vs heavy RPCs)
Prefer deadlines over open-ended contexts; alert on timeout rates

When it happens

Trigger: context.WithTimeout deadline elapses while the RPC is outstanding; parent context cancelled (e.g. HTTP client disconnected); manual cancelFunc invoked during the call.

Common situations: Slow server handler exceeding a short client timeout; cascading cancellation from an upstream request; deadline too tight for first-call setup (TCP dial + handshake included in the budget); network latency spikes.

Related errors

AI-assisted analysis of geektutu/7days-golang@cf36443821 (2026-09-03). Data as JSON: /api/errors/6b6e8ab6f3e5b43f. Report an issue: GitHub.