fix(config): validate rpc cache redis connection at startup

[raushan728]

config.kora.cache was completely skipped during config validation —
operators could pass kora config validate with a bad Redis URL that
only fails at runtime. Now mirrors the existing UsageLimitConfig
cache validation pattern.

---

[greptile-apps]

Greptile Summary

This PR closes a gap in the config validation pipeline where config.kora.cache was silently skipped, allowing a malformed or unreachable Redis URL to go undetected until runtime. The fix adds CacheValidator::validate_rpc_cache and wires it into the existing startup validation flow in ConfigValidator, mirroring the pattern already in place for UsageLimitConfig.

Key changes:

• New validate_rpc_cache method in CacheValidator checks URL presence, protocol format (redis:///rediss://), and live reachability via test_redis_connection.
• ConfigValidator now calls validate_rpc_cache when cache.enabled is true, propagating errors and warnings the same way as usage-limit validation.
• Three unit tests added covering: cache disabled, cache enabled with no URL, and invalid URL format.

Notable observations:

• The connection-failure code path (valid URL format but Redis unreachable) has no test coverage, even though it is the primary scenario this PR guards against. A test using an unreachable port (e.g. redis://localhost:54321) should be added to match the pattern used in the existing UsageLimitConfig tests.
• Unlike UsageLimitConfig, CacheConfig has no fallback_if_unavailable field, so any Redis connection failure at startup is a hard error. This is likely intentional (RPC caching is more infrastructure-critical than rate limiting), but operators should be aware that a transient Redis outage during deployment will prevent the service from starting.
• The warnings vector in validate_rpc_cache is always returned empty; a brief comment clarifying this is intentional (or adding fallback warning support in the future) would improve readability.

Confidence Score: 4/5

• Safe to merge with a minor test coverage gap for the Redis connection-failure path.
• The logic is correct and mirrors an existing, well-tested pattern. The only notable gap is the missing test for the connection-failure scenario, which is the central use case for this validation. No functional bugs were found; the change is additive and non-breaking.
• crates/lib/src/validator/cache_validator.rs — missing test for validate_rpc_cache when Redis is unreachable.

Important Files Changed

Filename	Overview
crates/lib/src/validator/cache_validator.rs	Adds validate_rpc_cache function that validates Redis URL presence, format, and reachability when cache is enabled. Logic is correct; missing a test for the connection-failure path which is the core scenario being guarded against.
crates/lib/src/validator/config_validator.rs	Wires validate_rpc_cache into the startup validation flow, mirroring the existing UsageLimitConfig pattern. The outer enabled guard is redundant (the function returns early on !enabled internally), but this is consistent with the existing code style.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Config Validation Start] --> B{cache.enabled?}
    B -- No --> C[Skip RPC cache validation]
    B -- Yes --> D[validate_rpc_cache]
    D --> E{cache.url present?}
    E -- No --> F[Error: no Redis URL configured]
    E -- Yes --> G{URL starts with redis:// or rediss://?}
    G -- No --> H[Error: invalid cache_url format]
    G -- Yes --> I[test_redis_connection]
    I -- OK --> J[No errors]
    I -- Err --> K[Error: RPC cache Redis connection failed]
    F --> L[Errors propagated to startup validator]
    H --> L
    K --> L
    J --> M[Startup proceeds]
    L --> N[Startup blocked]

Loading

_{Last reviewed commit: 9757514}

[raushan728]

Added connection failure test using unreachable port and clarified
warnings vector intent with a comment.

[raushan728]

@dev-jodee done. Sanitized both error messages — removed cache_url from
invalid format error and connection failure message to
prevent credentials leaking in logs.

[devin-ai-integration]

Devin Review found 1 potential issue.

View 3 additional findings in Devin Review.

[github-actions]

✅ Fork external live tests passed.

fork-external-live-pass:2a98ccfdeb77133586fcc7aede5f5357c86f89d0
run: https://github.com/solana-foundation/kora/actions/runs/22864370821

[raushan728]

Thanks for merging, @dev-jodee. Is there any other work here where I can help you? I'm free these days, so if there's something, I'd be happy to assist

[dev-jodee]

Hey @raushan728 thanks for all the work, I've created this issue if you want to take a crack at it #377

[raushan728]

@dev-jodee I can do but I really need your guidance and also how I show you my work — can I share a pdf or markdown with you?