Reduce flakiness in io.opentelemetry.instrumentation.lettuce.v5_1.LettuceSyncClientAuthTest.testAuthCommand()

[trask]

Automated attempt at fixing flakiness in io.opentelemetry.instrumentation.lettuce.v5_1.LettuceSyncClientAuthTest.testAuthCommand().

• Source: instrumentation/lettuce/lettuce-5.1/library/src/test/java/io/opentelemetry/instrumentation/lettuce/v5_1/LettuceSyncClientAuthTest.java
• Flaky executions in last 7d (this test): 158
• Flaky executions in last 7d (test container): 158
• Primary failed scan: https://develocity.opentelemetry.io/s/bqvb4f5tv7dm2

Recent failed/flaky scans

• bqvb4f5tv7dm2 (flaky, :instrumentation:lettuce:lettuce-5.1:library:test)
• efwa2zriqqnn2 (flaky, :instrumentation:lettuce:lettuce-5.1:library:testStableSemconv)
• oxxq225nktu7m (flaky, :instrumentation:lettuce:lettuce-5.1:library:testStableSemconv)
• g37v2b3ndn2mk (flaky, :instrumentation:lettuce:lettuce-5.1:library:test)
• ymjxe452fwpss (flaky, :instrumentation:lettuce:lettuce-5.1:library:test)

Flake history (per UTC day)

Day	flaky	failed	passed
2026-04-24	0	0	34
2026-04-25	0	0	113
2026-04-26	0	0	61
2026-04-27	0	0	93
2026-04-28	0	0	136
2026-04-29	0	0	111
2026-04-30	0	0	226
2026-05-01	92	0	0

Sample failure (from Develocity)

io.lettuce.core.RedisCommandExecutionException: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct?
> io.lettuce.core.RedisCommandExecutionException: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct?

Copilot diagnosis

Root cause

The auth fixture was mutating the inherited static Redis container by adding --requirepass and then starting it. If another lettuce 5.1 test class had already started that shared container without a password in the same JVM, the later command mutation did not reconfigure the running Redis process, so AUTH password failed with "called without any password configured". I opened two supplied Develocity scan URLs (bqvb4f5tv7dm2 and efwa2zriqqnn2); both scan pages were reachable but JS-rendered, and the captured failure lines supplied for both show the same Redis AUTH error.

Fix

• Added a shared newRedisServer() helper for constructing Redis test containers with the existing image, port, logging, and readiness settings.
• Made the default shared redisServer final so tests do not mutate its command configuration.
• Updated the auth test fixture to start its own password-protected Redis container using separate command arguments: redis-server, --requirepass, password.

Why this addresses the root cause

The auth test no longer depends on whether the inherited default container has already been started by another lettuce test class. Its Redis process is created with authentication configured before startup, so the AUTH password command exercises the intended authenticated-server path deterministically.

Risks / follow-ups

• The auth fixture now starts a separate Redis container, so maintainers should expect the test to keep its existing Testcontainers dependency and startup cost.
• If lettuce tests are later run with JUnit class-level parallelism, the remaining static client/host fields in the shared base class may need broader isolation beyond this single auth flake.

---

Review the diagnosis and the diff carefully before merging - automated fixes can mask flakiness instead of addressing the root cause.

[trask]

these library tests should get fixed by #18492 (which was targeting the javaagent tests)