Summary

• When a bidirectional write stream is closed by the server before delivering the gRPC status (e.g. the WriteStream handler returns CodeNodeIsNotLeader before reading any messages), the client's stream.Recv() can return io.EOF instead of the proper gRPC status error
• io.EOF was not classified as retriable in isRetriable(), so the batch retry logic treated it as a permanent failure
• This caused flaky TestLeaderHintWithClient failures where the DizzyShardManager forces the client to connect to a non-leader node — the server closes the stream immediately, the client gets EOF, and gives up instead of retrying with the leader hint

Root cause

In the WriteStream server handler (public_rpc_server.go:184-186), when the node is not the leader, getLeader() returns an error and the handler returns immediately — before ever calling stream.Recv(). This causes gRPC to close the server-side stream, and the client's Recv() can race between receiving the proper status error vs io.EOF.

The isRetriable() function checks status.Code(err), but status.Code(io.EOF) returns codes.OK which falls through to the non-retriable default case.

Fix

Add an explicit errors.Is(err, io.EOF) check before the gRPC status code switch, treating EOF as a retriable transient condition.

Test plan

• go vet ./oxia/internal/batch/... passes
• CI passes

🤖 Generated with Claude Code