• Store gRPC connection to properly close on reconnect, preventing goroutine leaks
• Fix reconnection loop logic that was inverted, causing immediate exit on success
• Add connection error detection to trigger reconnection on unavailable status
• Improve logging and add gRPC imports for connection management

Fix cache reconnection loop and connection leak handling

• Added conn field to store gRPC connection for proper cleanup on reconnect
• Imported gRPC packages for connection and error code handling
• Modified connectGRPCConnectionToRelayerCacheService() to return connection alongside client
• Fixed inverted reconnection loop logic (was returning on error, now returns on success)
• Added resetOnConnectionError() method to detect unavailable errors and trigger reconnection
• Integrated error handling in GetEntry() and SetEntry() to call resetOnConnectionError()
• Enhanced logging with more descriptive messages for connection lifecycle events
• Added comments explaining goroutine leak prevention and reconnection logic

protocol/performance/cache.go

Description

The new code calls r.conn.Close() without checking/handling its returned error, which commonly
triggers errcheck in golangci-lint. This can fail make lint and also hides close failures that
could matter during reconnect/shutdown.

Code

protocol/performance/cache.go[R77-80]

+			if r.conn != nil {
+				utils.LavaFormatDebug("closing previous cache gRPC connection before replacing", utils.LogAttr("address", r.address))
+				r.conn.Close()
+			}

Evidence

PR Compliance ID 5 requires zero golangci-lint warnings; grpc.ClientConn.Close() returns an
error, and the added code ignores it by calling r.conn.Close() with no check/logging.

AGENTS.md
protocol/performance/cache.go[77-80]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`r.conn.Close()` returns an error, but the new reconnect logic ignores it. This is likely to trigger `golangci-lint` (`errcheck`) and can hide close failures.
## Issue Context
The reconnect path closes a previous `*grpc.ClientConn` before replacing it.
## Fix Focus Areas
- protocol/performance/cache.go[77-80]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

resetOnConnectionError() decodes error codes using google.golang.org/grpc/status.Code, while other
gRPC paths in this repo commonly use github.com/gogo/status.Code. Errors produced/handled via
gogo/status may not be recognized here, preventing codes.Unavailable from triggering a client reset
and reconnect.

Code

protocol/performance/cache.go[R129-132]

+	code := status.Code(err)
+	if code != codes.Unavailable {
+		return
+	}

Evidence

cache.resetOnConnectionError uses the google grpc/status package to extract codes, but core gRPC
error handling in lavasession (and other paths) uses github.com/gogo/status; mixing these can cause
code extraction to fail for gogo/status errors, so the Unavailable gate may never trip.

protocol/performance/cache.go[1-15]
protocol/performance/cache.go[123-132]
protocol/lavasession/common.go[3-28]
protocol/lavasession/common.go[59-62]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`resetOnConnectionError()` uses `google.golang.org/grpc/status.Code(err)` to decide whether to clear the cache client and trigger reconnection. Elsewhere in the repo, gRPC error-code extraction is typically done with `github.com/gogo/status`, so this mismatch can prevent recognizing `codes.Unavailable` for some error types.
### Issue Context
The cache client is built on gogoproto-generated gRPC stubs (cosmos/gogoproto), and other gRPC call paths in the repo extract codes via `github.com/gogo/status`. Aligning the status decoding avoids silent failure to trigger reconnection.
### Fix Focus Areas
- protocol/performance/cache.go[1-15]
- protocol/performance/cache.go[123-132]
- protocol/lavasession/common.go[3-28]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When r.ctx is canceled, reconnectClient() exits without closing the stored *grpc.ClientConn, and
Cache exposes no Close method to close it during shutdown. This can leave gRPC internal goroutines
running after shutdown and contradicts the new conn field’s stated shutdown intent.

Code

protocol/performance/cache.go[R109-111]

  	case <-r.ctx.Done():
+			utils.LavaFormatInfo("cache service reconnection loop exiting (context cancelled)", utils.LogAttr("address", r.address))
  		return

Evidence

The PR adds a stored *grpc.ClientConn with an explicit comment about closing it on shutdown, but the
only Close call is on successful reconnect replacement; the ctx.Done() shutdown path returns without
closing r.conn, and there is no Cache.Close() to do so.

protocol/performance/cache.go[17-24]
protocol/performance/cache.go[107-112]
protocol/performance/cache.go[140-191]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The cache client now stores a `*grpc.ClientConn` (comment says it can be closed on shutdown), but there is no shutdown implementation: on `ctx.Done()` the reconnect loop exits without closing the connection, and `Cache` exposes no `Close()` method.
### Issue Context
`*grpc.ClientConn` maintains internal goroutines; without `Close()` they can survive beyond the cache lifecycle in tests or in processes that continue running after cache context cancellation.
### Fix Focus Areas
- protocol/performance/cache.go[17-24]
- protocol/performance/cache.go[93-121]
- protocol/performance/cache.go[140-191]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.