Summary
Follow-up to #816 (fix for #815). The system_cleanup handler that prunes Redis
queue metadata currently has ~0% patch coverage on its core branch, and there is
no straightforward way to unit-test it today. This issue tracks making that code
path testable.
Background
#816 changed handle_cleanup_request in
src/jobs/handlers/system_cleanup_handler.rs to source the Redis pool from the
queue backend instead of the transaction repository, so cleanup runs whenever
the queue backend is Redis regardless of REPOSITORY_STORAGE_TYPE. Codecov
flagged the changed lines as uncovered.
Why it's hard to cover right now
All of the changed lines sit behind the backend_type() == Redis guard, and the
only way to obtain a non-None redis_connections() is through Queue::setup(),
which opens live Redis ConnectionManagers. Consequently:
- A plain unit test cannot reach those lines without a running Redis.
- CI has no Redis service in the coverage job (
.github/workflows/ci.yaml), and
the existing *_redis.rs tests are all #[ignore]d, so a Redis-gated
integration test would not run in CI (and thus wouldn't contribute coverage).
handle_cleanup_request takes a concrete ThinData<DefaultAppState> (hard-wired
to the concrete JobProducer), so a MockJobProducerTrait cannot be injected
as-is.
Proposed options (any one, or a combination)
-
Make the inner handler generic over the job producer, mirroring the existing
relayer_health_check_handler pattern (public concrete wrapper +
generic _impl). This allows injecting MockJobProducerTrait and unit-testing
the two skip branches (non-Redis backend; Redis backend with no connections)
in normal CI — covers most of the diff without any infra.
-
Add a Redis service to the coverage CI job and either un-#[ignore] a
focused integration test or add a new one that exercises the full
prune path (<queue>:{done,failed,dead} + :data/:data::result).
-
Add a Redis-gated #[ignore]d integration test (mirrors the current
*_redis.rs convention) that documents/verifies the end-to-end behavior even
if it doesn't count toward CI coverage.
Summary
Follow-up to #816 (fix for #815). The
system_cleanuphandler that prunes Redisqueue metadata currently has ~0% patch coverage on its core branch, and there is
no straightforward way to unit-test it today. This issue tracks making that code
path testable.
Background
#816 changed
handle_cleanup_requestinsrc/jobs/handlers/system_cleanup_handler.rsto source the Redis pool from thequeue backend instead of the transaction repository, so cleanup runs whenever
the queue backend is Redis regardless of
REPOSITORY_STORAGE_TYPE. Codecovflagged the changed lines as uncovered.
Why it's hard to cover right now
All of the changed lines sit behind the
backend_type() == Redisguard, and theonly way to obtain a non-
Noneredis_connections()is throughQueue::setup(),which opens live Redis
ConnectionManagers. Consequently:.github/workflows/ci.yaml), andthe existing
*_redis.rstests are all#[ignore]d, so a Redis-gatedintegration test would not run in CI (and thus wouldn't contribute coverage).
handle_cleanup_requesttakes a concreteThinData<DefaultAppState>(hard-wiredto the concrete
JobProducer), so aMockJobProducerTraitcannot be injectedas-is.
Proposed options (any one, or a combination)
Make the inner handler generic over the job producer, mirroring the existing
relayer_health_check_handlerpattern (public concrete wrapper +generic
_impl). This allows injectingMockJobProducerTraitand unit-testingthe two skip branches (non-Redis backend; Redis backend with no connections)
in normal CI — covers most of the diff without any infra.
Add a Redis service to the coverage CI job and either un-
#[ignore]afocused integration test or add a new one that exercises the full
prune path (
<queue>:{done,failed,dead}+:data/:data::result).Add a Redis-gated
#[ignore]d integration test (mirrors the current*_redis.rsconvention) that documents/verifies the end-to-end behavior evenif it doesn't count toward CI coverage.