Fix nil pointer dereference panic in GRPC server methods during cluster initialization

[Copilot]

The application was experiencing flaky test failures with segmentation fault panics in the GRPC Delete method and related operations. The panic occurred when tests started before the Raft cluster was fully initialized:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x15fa6d9]

goroutine 59200 [running]:
github.com/bootjp/elastickv/adapter.GRPCServer.Delete(...)
	/home/runner/work/elastickv/elastickv/adapter/grpc.go:166 +0x479

Root Cause

When the Raft cluster is not ready and coordinator.Dispatch() fails, it can return (nil, error). However, the error handling code was attempting to access res.CommitIndex on the nil result:

res, err := r.coordinator.Dispatch(reqs)
if err != nil {
    return &pb.DeleteResponse{
        CommitIndex: res.CommitIndex,  // ← panic here when res is nil
    }, errors.WithStack(err)
}

This affected four GRPC methods: RawPut, RawDelete, Put, and Delete.

Solution

Fixed the error handling to always use uint64(0) for CommitIndex when errors occur, which is semantically correct since failed operations should not report a commit index:

res, err := r.coordinator.Dispatch(reqs)
if err != nil {
    return &pb.DeleteResponse{
        CommitIndex: uint64(0),  // Always use 0 for failed operations
        Success:     false,
    }, errors.WithStack(err)
}

Testing

• Verified the code builds successfully with the changes
• Confirmed that the fix prevents nil pointer dereference panics
• Tested that error responses now consistently return CommitIndex: 0 when the coordinator fails to dispatch requests

This fix makes the system more robust during cluster initialization and eliminates the flaky test failures caused by timing issues with Raft cluster readiness.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[bootjp]

エラーのときは常に uint64(0) で良いのではないですか？

[bootjp]

@copilot

[Copilot]

You're absolutely right! Simplified the error handling to always use uint64(0) for CommitIndex when there's an error, which is cleaner and more semantically correct. Applied to all four methods: RawPut, RawDelete, Put, and Delete. Commit: d056645

[bootjp]

LGTM