vmruiz/telegramarr

Watch

Fork 0

[Tests] test_job_recovery dispatcher tests need a Redis on 127.0.0.1:6379 #6

New issue

Closed

opened 2026-08-23 13:57:35 +02:00 by vmruiz · 1 comment

vmruiz commented

2026-08-23 13:57:35 +02:00

Owner

Summary

Three tests in tests/test_job_recovery.py fail on a clean checkout because they reach for a real Redis that is not running:

test_download_dispatcher_claims_one_media_slot
test_download_dispatcher_reschedules_after_body_error
test_download_dispatcher_reschedules_when_lock_is_held_elsewhere

All three fail with the same error:

ConnectionRefusedError: [Errno 111] Connection refused

The tests are not exercising the dispatcher logic — they are blocked at the very first Redis connect() call.

Reproduction

$ uv run pytest tests/test_job_recovery.py --no-header
...
FAILED tests/test_job_recovery.py::test_download_dispatcher_claims_one_media_slot
FAILED tests/test_job_recovery.py::test_download_dispatcher_reschedules_after_body_error
FAILED tests/test_job_recovery.py::test_download_dispatcher_reschedules_when_lock_is_held_elsewhere
=================== 3 failed, 4 passed, 8 warnings in 4.49s ====================

No Redis is required to be running. tests/conftest.py sets REDIS_URL=redis://127.0.0.1:0/0 (database 0 on a hypothetical local Redis), but these particular tests evidently bypass that and try 127.0.0.1:6379 directly.

Impact

uv run pytest is red on a fresh checkout. CI presumably works because it spins up Redis as a service, but a developer running tests locally without a Redis installed hits 3 spurious failures and is left wondering if the dispatcher is broken.

Suggested direction (out of scope here)

Make the test suite use fakeredis (already a transitive dep in some places) or a real local Redis started by the test fixture, so the dispatcher is exercised without a sidecar.
Alternatively, gate the offending tests behind a pytest.mark.skipif(not redis_available, ...) so they only run when Redis is reachable.

Out of scope for #5

This is purely a pre-existing test-infra issue. It is being filed separately so the seed-demo PR (and any other PR) can pass uv run pytest cleanly on a clean checkout.

## Summary Three tests in `tests/test_job_recovery.py` fail on a clean checkout because they reach for a real Redis that is not running: - `test_download_dispatcher_claims_one_media_slot` - `test_download_dispatcher_reschedules_after_body_error` - `test_download_dispatcher_reschedules_when_lock_is_held_elsewhere` All three fail with the same error: ``` ConnectionRefusedError: [Errno 111] Connection refused ``` The tests are not exercising the dispatcher logic — they are blocked at the very first Redis `connect()` call. ## Reproduction ``` $ uv run pytest tests/test_job_recovery.py --no-header ... FAILED tests/test_job_recovery.py::test_download_dispatcher_claims_one_media_slot FAILED tests/test_job_recovery.py::test_download_dispatcher_reschedules_after_body_error FAILED tests/test_job_recovery.py::test_download_dispatcher_reschedules_when_lock_is_held_elsewhere =================== 3 failed, 4 passed, 8 warnings in 4.49s ==================== ``` No Redis is required to be running. `tests/conftest.py` sets `REDIS_URL=redis://127.0.0.1:0/0` (database 0 on a hypothetical local Redis), but these particular tests evidently bypass that and try `127.0.0.1:6379` directly. ## Impact `uv run pytest` is red on a fresh checkout. CI presumably works because it spins up Redis as a service, but a developer running tests locally without a Redis installed hits 3 spurious failures and is left wondering if the dispatcher is broken. ## Suggested direction (out of scope here) - Make the test suite use `fakeredis` (already a transitive dep in some places) or a real local Redis started by the test fixture, so the dispatcher is exercised without a sidecar. - Alternatively, gate the offending tests behind a `pytest.mark.skipif(not redis_available, ...)` so they only run when Redis is reachable. ## Out of scope for #5 This is purely a pre-existing test-infra issue. It is being filed separately so the seed-demo PR (and any other PR) can pass `uv run pytest` cleanly on a clean checkout.

vmruiz commented

2026-08-23 14:00:37 +02:00

Author

Owner

Closing — this is expected outside Docker

Confirmed: these tests rely on a real Redis sidecar, which only exists in the Docker dev stack (docker compose up -d db redis). On a bare-metal checkout without Redis running, the 3 ConnectionRefusedError failures are expected and not a bug.

Closing in favor of documenting this expectation. No code change needed in this PR.

## Closing — this is expected outside Docker Confirmed: these tests rely on a real Redis sidecar, which only exists in the Docker dev stack (`docker compose up -d db redis`). On a bare-metal checkout without Redis running, the 3 `ConnectionRefusedError` failures are expected and not a bug. Closing in favor of documenting this expectation. No code change needed in this PR.

vmruiz closed this issue

2026-08-23 14:00:37 +02:00

vmruiz referenced this issue from a commit

2026-08-23 14:12:36 +02:00

feat(cli): add seed-demo command for quick test environments

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

vmruiz/telegramarr#6

No description provided.

Rows
Columns