Harden Redis wait step in CI docker service startup

[nanaf6203-bit]

Context

ci.yml waits for the Redis service container using a fragile docker exec + --filter ancestor command that can match the wrong container or race container startup.

Problem

Flaky CI: tests start before Redis is ready (connection errors) or the wait command targets the wrong container after runner image changes.

Proposed approach

Replace with a bounded retry loop (until redis-cli ping), explicit container name via docker ps --filter name=, or use service health options (options: --health-cmd)

Acceptance criteria

• Wait step is deterministic across runner updates
• Failure produces clear logs
• CI green on repeated runs (document rerun evidence)

[Ade20000]

@Ade20000 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hey, please assign, i can fix this very fast

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ade20000 to this issue.

[Ire12]

@Ire12 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hi maintainer, kindly assign this issue to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ire12 to this issue.

[Mirabel64]

@Mirabel64 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

HI maitainer kindly assign me please

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Mirabel64 to this issue.

[Adedoyinjr]

@Adedoyinjr has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hello, I’d like to take on issue #1099.

I’ll replace the fragile Redis startup check with a bounded readiness retry using "redis-cli ping" and an explicit container/service target, so the workflow waits for Redis instead of racing the test startup.

I’ll also make failures produce clear diagnostic logs and verify the workflow remains deterministic across repeated CI runs.

I’m confident I can keep this change focused and provide the required rerun evidence.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Adedoyinjr to this issue.

[paulddeveloper-droid]

@paulddeveloper-droid has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

I can harden the Redis CI startup check with a bounded retry loop and explicit container targeting to avoid flaky readiness checks.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @paulddeveloper-droid to this issue.

[drips-wave]

Congratulations, @Mirabel64! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @Mirabel64: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊