fix(rate-limiter): production hardening — Redis connection path

[gandhipratik203]

Summary

Wraps Client::get_multiplexed_tokio_connection().await in a 2-second tokio::time::timeout so the rate-limiter fails fast when the configured Redis endpoint accepts TCP but never speaks at the application layer (plain redis:// against a TLS-required server, network ACL drops, firewalled cluster, etc.). Without the bound, the call blocks indefinitely; the framework's outer 30-second plugin timeout eventually kills the hook, and fail_mode cannot engage because the connection-acquisition future never returns to surface an error.

The timeout error is mapped into a redis::ErrorKind::IoError-shaped RedisError so the existing fail_mode path routes it the same way as any other connection-side failure.

Test coverage

Two layers — both fail-by-hang against the prior implementation, both pass against this commit:

• Rust unit test (redis_backend::tests::connection_async_fails_fast_against_hanging_redis) — binds a TCP listener that accepts but never reads/writes; asserts connection_async returns within ~3s with an IoError-shaped error.
• Python integration test (TestRedisFailModeAndViolationContext::test_hanging_redis_fails_fast_via_connect_timeout) — same setup pattern at the public-API layer; asserts tool_pre_invoke completes within ~5s and the default fail_mode=open allows the request through.

Each test is wrapped with an outer runaway-guard (tokio::time::timeout(5s) / asyncio.wait_for(..., 10.0)) so a regression doesn't hang the test run.

Full local gate

cargo fmt -- --check                  clean
cargo clippy -- -D warnings           clean
cargo test --release -p rate_limiter  59 passed
make test-integration                 60 passed

Configurability

The 2-second CONNECT_TIMEOUT is a hardcoded constant for now to keep the change small. Promoting it to a redis_connect_timeout_ms config key (extending the existing config-key list and warning machinery) is a trivial follow-up if operators in slow-network deployments need a longer budget.

[lucarlig]

Rechecked current head 0e9bbeb after the update. Thanks for the version bump; that part is fixed now.

Still missing from the previous review:

1. test_hanging_redis_fails_fast_via_connect_timeout still only covers default fail_mode=open. Please add the same hanging TCP-accepted/app-silent path for fail_mode=closed and assert the BACKEND_UNAVAILABLE response shape (continue_processing=false, 503, Retry-After).

2. The Redis connect timeout is still a hard-coded Duration::from_secs(2) inside connection_async. The earlier concern remains: this is operator policy and can flip slow managed/TLS Redis paths into fail-open/fail-closed without a tuning knob. Please move this through config/defaults/unknown-key handling, or explicitly justify why this PR should ship with a fixed constant.

3. The Rust unit test still accepts ResponseError even though the implementation maps the explicit timeout to IoError with connection timeout context. Please tighten the assertion to the exact timeout contract.

I did not rerun the test suite; this is a diff re-check only.

[gandhipratik203]

Thanks for the re-check.

On (2) — kept hardcoded, with rationale captured inline at redis_backend.rs so it's discoverable on next read.

The trade-off honestly: 2s is on the aggressive side compared to Lettuce/ioredis (10s) or .NET StackExchange (5s), and you're right that it's operator policy in principle. The reason we'd like to leave it as a constant for this PR: the plugin's config surface is small by design, and adding a knob that the vast majority of operators won't tune expands the schema for everyone else. 2 seconds covers typical production paths comfortably — intra-VPC and cross-AZ Redis connection establishment is well under 100ms, and managed Redis with TLS handshake adds only ~100-300ms on top, so the "slow managed/TLS Redis flip" requires a genuinely unusual ~1.5+ second handshake to bite.

If a deployment with deliberately slow networks surfaces, promoting this to redis_connect_timeout_ms is a small, well-scoped change — the engine's config-validation machinery (KNOWN list, lib.rs defaults, unknown-key warning) is already there. Happy to file it as a separate follow-up issue if you'd prefer to track it.

Let me know if you'd rather we add the knob now anyway — defensible either way and your call.

[gandhipratik203]

On (1) and (3) — both addressed in bc0267b:

• (1) Added test_hanging_redis_with_fail_mode_closed_blocks_with_backend_unavailable as a sibling to the existing fail_mode=open hanging-Redis test. Same socket setup; flips fail_mode to closed and asserts continue_processing=False, violation.code='BACKEND_UNAVAILABLE', violation.http_status_code=503, and Retry-After present in violation.http_headers. The pair now pin both halves of the operator's policy under the hanging-Redis failure shape.

• (3) Tightened the Rust unit test from matches!(kind, IoError | ResponseError) to assert_eq!(err.kind(), IoError). Pins the exact contract that the timeout maps into the same fail-mode-routed error category as any other connection-side failure.

[lucarlig]

LGTM