• Skip ConnectionRefusals and MarkUnhealthy on client-side context cancellation
  - Guard both connection and relay paths to check ctx.Err() before attributing errors to provider
• Make minimum relay timeout configurable via --min-relay-timeout flag
  - Convert hardcoded MinimumTimePerRelayDelay from 1s to configurable variable
  - Add ValidateAndCapMinRelayTimeout() to prevent misconfiguration by capping to 50% of
  DefaultTimeout
• Add comprehensive test coverage for timeout validation and GetTimePerCu behavior

Add minimum relay timeout flag constant

• Add MinRelayTimeoutFlagName constant for the new --min-relay-timeout flag

protocol/common/cobra_common.go

Make minimum relay timeout configurable with validation

• Convert MinimumTimePerRelayDelay from constant to configurable variable
• Add ValidateAndCapMinRelayTimeout() function to cap MinimumTimePerRelayDelay at 50% of
 DefaultTimeout if misconfigured
• Add utils import for logging warnings
• Update documentation comments for DefaultTimeout and MinimumTimePerRelayDelay

protocol/common/timeout.go

Add timeout validation and GetTimePerCu floor tests

• Add 9 comprehensive test cases for ValidateAndCapMinRelayTimeout() covering no-cap, equal,
 greater, and half-of-default scenarios
• Add 3 test cases for GetTimePerCu() respecting MinimumTimePerRelayDelay floor with default,
 raised, and post-validation floors
• Add resetTimeoutGlobals() helper to prevent test pollution

protocol/common/timeout_test.go

Description

protocol/common/timeout_test.go is added without a trailing newline (`\ No newline at end of
file`), which indicates the file is not fully gofmt-clean. This can cause formatting diffs and
tooling/lint inconsistencies.

Code

protocol/common/timeout_test.go[106]

+}

Evidence

The compliance rule requires modified Go files to be gofmt-clean; the PR diff explicitly marks the
new test file as missing a final newline, which gofmt expects.

AGENTS.md
protocol/common/timeout_test.go[106-106]

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 new Go test file is missing a trailing newline, which violates gofmt-clean expectations.
## Issue Context
The PR diff indicates `\ No newline at end of file` for `protocol/common/timeout_test.go`.
## Fix Focus Areas
- protocol/common/timeout_test.go[106-106]

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

Description

ValidateAndCapMinRelayTimeout can set MinimumTimePerRelayDelay to DefaultTimeout/2, which becomes 0
when --default-processing-timeout=0s (or extremely small), causing downstream CapContextTimeout(…,0)
to create an immediately-expired context and fail relays instantly for low-CU requests.

Code

protocol/common/timeout.go[R36-48]

+// ValidateAndCapMinRelayTimeout ensures MinimumTimePerRelayDelay < DefaultTimeout.
+// If not, it caps MinimumTimePerRelayDelay at 50% of DefaultTimeout and logs a warning.
+func ValidateAndCapMinRelayTimeout() {
+	if MinimumTimePerRelayDelay >= DefaultTimeout {
+		capped := DefaultTimeout / 2
+		utils.LavaFormatWarning("min-relay-timeout >= default-processing-timeout, capping to 50% of processing timeout",
+			nil,
+			utils.LogAttr("min_relay_timeout", MinimumTimePerRelayDelay),
+			utils.LogAttr("default_processing_timeout", DefaultTimeout),
+			utils.LogAttr("capped_to", capped),
+		)
+		MinimumTimePerRelayDelay = capped
+	}

Evidence

The new validation caps the minimum relay floor to DefaultTimeout/2 without guarding against
DefaultTimeout<=0, which can set the floor to 0. Relay timeout is derived from GetTimePerCu (which
uses that floor), then processing timeout is applied through NodeUrl.LowerContextTimeout which calls
CapContextTimeout; when timeout=0 and the parent context has no deadline (remaining time is
MaxInt64), CapContextTimeout uses context.WithTimeout(ctx, 0), producing an immediate deadline and
failing the request.

protocol/common/timeout.go[28-83]
protocol/chainlib/common.go[110-115]
protocol/chainlib/common.go[362-377]
protocol/common/endpoints.go[138-147]

Agent prompt

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

## Issue description
`ValidateAndCapMinRelayTimeout()` can set `MinimumTimePerRelayDelay` to `DefaultTimeout/2`. If `DefaultTimeout` is configured as `0s` (or becomes very small), the computed cap becomes `0`, which later leads to `CapContextTimeout(ctx, 0)` and immediate request timeouts.
### Issue Context
- `MinimumTimePerRelayDelay` participates in relay timeout calculation via `GetTimePerCu()` / `GetRelayTimeout()`.
- `processingTimeout` is enforced via `NodeUrl.LowerContextTimeout()` → `CapContextTimeout()`.
### Fix Focus Areas
- Add explicit validation that `DefaultTimeout > 0` (and optionally `MinimumTimePerRelayDelay > 0`) and either:
- return an error / fatal at startup for invalid values, OR
- clamp the computed `capped` value to a safe minimum (e.g., `time.Millisecond` or `time.Second`) so it never becomes `0`.
- Consider also guarding the cap path for `DefaultTimeout < 2` nanoseconds (integer division rounding to 0).
- protocol/common/timeout.go[36-49]
- protocol/common/timeout.go[78-83]
- protocol/chainlib/common.go[110-115]
- protocol/common/endpoints.go[138-147]

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

Description

Multiple closely-related cases for ValidateAndCapMinRelayTimeout() are implemented as separate
tests instead of a table-driven test, reducing consistency and making extension harder. This
conflicts with the table-driven style requirement for multi-case validations.

Code

protocol/common/timeout_test.go[R22-64]

+func TestValidateAndCapMinRelayTimeout_NoCapNeeded(t *testing.T) {
+	resetTimeoutGlobals(t, MinimumTimePerRelayDelay, DefaultTimeout)
+
+	MinimumTimePerRelayDelay = 5 * time.Second
+	DefaultTimeout = 30 * time.Second
+
+	ValidateAndCapMinRelayTimeout()
+
+	require.Equal(t, 5*time.Second, MinimumTimePerRelayDelay, "should not be modified when min < default")
+}
+
+func TestValidateAndCapMinRelayTimeout_EqualTriggersCap(t *testing.T) {
+	resetTimeoutGlobals(t, MinimumTimePerRelayDelay, DefaultTimeout)
+
+	MinimumTimePerRelayDelay = 30 * time.Second
+	DefaultTimeout = 30 * time.Second
+
+	ValidateAndCapMinRelayTimeout()
+
+	require.Equal(t, 15*time.Second, MinimumTimePerRelayDelay, "should cap to 50% when min == default")
+}
+
+func TestValidateAndCapMinRelayTimeout_GreaterTriggersCap(t *testing.T) {
+	resetTimeoutGlobals(t, MinimumTimePerRelayDelay, DefaultTimeout)
+
+	MinimumTimePerRelayDelay = 60 * time.Second
+	DefaultTimeout = 30 * time.Second
+
+	ValidateAndCapMinRelayTimeout()
+
+	require.Equal(t, 15*time.Second, MinimumTimePerRelayDelay, "should cap to 50% when min > default")
+}
+
+func TestValidateAndCapMinRelayTimeout_CapIsHalfOfDefault(t *testing.T) {
+	resetTimeoutGlobals(t, MinimumTimePerRelayDelay, DefaultTimeout)
+
+	DefaultTimeout = 20 * time.Second
+	MinimumTimePerRelayDelay = 25 * time.Second
+
+	ValidateAndCapMinRelayTimeout()
+
+	require.Equal(t, DefaultTimeout/2, MinimumTimePerRelayDelay)
+}

Evidence

The checklist requires updated tests to use table-driven style when multiple cases are being
validated; the added tests repeat the same arrange/act/assert structure across several functions and
are suitable for a single table-driven test.

AGENTS.md
protocol/common/timeout_test.go[22-64]

Agent prompt

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

## Issue description
Several tests validate the same function with different inputs using repetitive standalone test functions; these should be consolidated into a table-driven test.
## Issue Context
The suite for `ValidateAndCapMinRelayTimeout()` repeats the same setup and assertions with only duration values changing.
## Fix Focus Areas
- protocol/common/timeout_test.go[22-64]

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

Description

fetchEndpointConnectionFromConsumerSessionWithProvider skips incrementing ConnectionRefusals for any
ctx.Err()!=nil (including context.DeadlineExceeded) while logging "request context canceled", which
can suppress refusal tracking under deadline-expired requests and produces misleading logs.

Code

protocol/lavasession/consumer_types.go[R780-788]

+					if ctx.Err() != nil {
+						utils.LavaFormatDebug("skipping ConnectionRefusals increment: request context canceled",
+							utils.LogAttr("err", err),
+							utils.LogAttr("ctx_err", ctx.Err()),
+							utils.LogAttr("provider endpoint", networkAddress),
+							utils.LogAttr("GUID", ctx),
+						)
+						return nil, false
+					}

Evidence

The new check uses ctx.Err() != nil, which includes both cancellation and deadline-exceeded;
however the log message and the smart-router counterpart logic specifically target cancellation
(errors.Is(err, context.Canceled)). The codebase already distinguishes deadline-exceeded
explicitly via ContextOutOfTime, suggesting this consumer-side condition is overly
broad/inconsistent.

protocol/lavasession/consumer_types.go[773-807]
protocol/rpcsmartrouter/rpcsmartrouter_server.go[1833-1845]
protocol/common/timeout.go[66-68]
protocol/lavasession/consumer_types.go[482-505]

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 consumer endpoint connection code currently treats any `ctx.Err()!=nil` as a cancellation case, skipping `ConnectionRefusals++` and logging "request context canceled". This conflates `context.Canceled` and `context.DeadlineExceeded` and is inconsistent with the smart-router direct relay logic, which checks `errors.Is(err, context.Canceled)`.
### Issue Context
- `ctx.Err()` may be `context.DeadlineExceeded` when the request times out.
- Skipping refusal increments on deadline-exceeded can hide slow/unreachable endpoints under tight deadlines.
### Fix Focus Areas
- Change the condition to specifically detect cancellation (e.g., `errors.Is(ctx.Err(), context.Canceled)` or `errors.Is(err, context.Canceled)`) before skipping refusal increments.
- Update the log message to match the actual condition (canceled vs deadline exceeded).
- protocol/lavasession/consumer_types.go[779-807]
- protocol/rpcsmartrouter/rpcsmartrouter_server.go[1833-1845]

ⓘ 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.