geektutu/7days-golang · error

server returned: %v

Error message

server returned: %v

What it means

In the day7-proto-buf build, httpGetter.Get (returning only error, with the payload going to a proto message out-parameter) rejects any non-200 status from a peer with "server returned: %v". The peer's handler may return status codes like 400/500 when it cannot serve the key, and this client turns that into a Go error.

Source

Thrown at gee-cache/day7-proto-buf/geecache/http.go:127

type httpGetter struct {
	baseURL string
}

func (h *httpGetter) Get(in *pb.Request, out *pb.Response) error {
	u := fmt.Sprintf(
		"%v%v/%v",
		h.baseURL,
		url.QueryEscape(in.GetGroup()),
		url.QueryEscape(in.GetKey()),
	)
	res, err := http.Get(u)
	if err != nil {
		return err
	}
	defer res.Body.Close()

	if res.StatusCode != http.StatusOK {
		return fmt.Errorf("server returned: %v", res.Status)
	}

	bytes, err := ioutil.ReadAll(res.Body)
	if err != nil {
		return fmt.Errorf("reading response body: %v", err)
	}

	if err = proto.Unmarshal(bytes, out); err != nil {
		return fmt.Errorf("decoding response body: %v", err)
	}

	return nil
}

var _ PeerGetter = (*httpGetter)(nil)

View on GitHub (pinned to cf36443821)

Solutions

1. Use the status in the error to locate the failing peer and check its logs
2. Ensure all nodes run protocol-compatible (day7 protobuf) versions
3. Verify the peer pool addresses/basePath match the serving handlers
4. Add failover/retry for transient peer unavailability

Example fix

// before
// old day5-style peer in the ring can't answer protobuf requests
// after
// register only day7 nodes in the consistent-hash ring and keep versions in sync

// ensure the peer speaks the day7 protobuf protocol before fetching
// (version probe or shared build-info endpoint)
if !peerSupportsProto(peerURL) {
    return errors.New("peer does not support protobuf protocol")
}

err := g.Get(key, &out) // day7 signature: payload into proto out-param
if err != nil && strings.Contains(err.Error(), "server returned:") {
    log.Printf("peer fetch failed: %v; loading locally", err)
    return g.getLocally(key) // fall back to local Getter
}

When it happens

Trigger: group.Get routed to a peer whose handler writes a non-200 status (e.g. its own 'key is required' 400, internal 500); stale peer registration pointing at a wrong endpoint (404).

Common situations: Mixed-version cluster where an older peer returns an unexpected status; peer failing to unmarshal/serve and responding 500; proxy returning 502 when the peer is down.

Related errors

• server returned: %v
• reading response body: %v
• server returned: %v
• reading response body: %v
• reading response body: %v

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