Gap-analysis tests silently connect to real Redis instead of the mock, causing flaky/order-dependent failures

[DevPatils]

Description

Several tests in application/tests/web_main_test.py that cover the
/rest/v1/map_analysis endpoint mock the Redis connection (redis.from_url)
and job queueing (rq.Queue.enqueue_call), but application/utils/redis.py's
connect() function has a code path that bypasses both mocks whenever
REDIS_HOST and REDIS_PORT are set — which they are by default for anyone
following this project's own documented local setup (.env.example sets
REDIS_HOST=localhost / REDIS_PORT=6379, and cre.py calls
load_dotenv() unconditionally at import time). This causes these tests to
silently connect to a real local Redis instance instead of the mock,
producing flaky, order-dependent, environment-dependent failures.

Demo

Screen recording showing the actual bypass happening in real time: the
Redis key is empty, the "mocked" test runs, and the key now exists in real
Redis with a real ~36-hour TTL — proving the test wrote to a real server
despite being fully mocked on paper.

Recording.2026-08-10.142808.mp4

Steps to reproduce

Ensure a local Redis is reachable at localhost:6379 (e.g. via
make start-containers), and that .env has REDIS_HOST=localhost and
REDIS_PORT=6379 set (the documented default from .env.example).

Step 1 — confirm the target key doesn't exist yet:

docker exec <redis-container> redis-cli GET "ga:inflight:aaa >> bbb"

Result: nothing (key absent).

Step 2 — run the test:

python -m unittest application.tests.web_main_test.TestMain.test_gap_analysis_create_job_id -v

Step 3 — check the same key again immediately after:

docker exec <redis-container> redis-cli GET "ga:inflight:aaa >> bbb"

docker exec <redis-container> redis-cli TTL "ga:inflight:aaa >> bbb"

Result: now returns a real value with a real ~36-hour TTL, proving the test
wrote directly to real Redis via conn.set(...) / conn.expire(...) in
application/web/web_main.py (map_analysis()), regardless of whether the
test's own assertion happened to pass or fail that run.

Definitive root-cause isolation — the same test flips outcome purely
based on this one condition. With Redis env vars blocked from loading:

$env:REDIS_HOST=""; $env:REDIS_PORT=""
python -m unittest application.tests.web_main_test.TestMain.test_gap_analysis_create_job_id -v

Result: OK.

With .env's real values loaded (the default/documented setup):

python -m unittest application.tests.web_main_test.TestMain.test_gap_analysis_create_job_id -v

Result: FAILS intermittently depending on what's cached in real Redis.

Expected behavior

These tests should be fully isolated from any real Redis instance
regardless of the local environment/.env configuration — mocking
redis.from_url should be sufficient (or the correct branch of
connect() should also be mocked/patched).

Actual behavior

application/utils/redis.py's connect() has three branches:

def connect():
    redis_url = os.getenv("REDIS_URL", "redis://localhost:6379")
    if os.getenv("REDIS_HOST") and os.getenv("REDIS_PORT"):
        return redis.StrictRedis(host=..., port=..., ...)   # never mocked by the tests
    elif redis_url:
        if redis_url == "redis://localhost:6379":
            return redis.from_url(redis_url)                 # this is the only branch the tests mock
        else:
            return redis.Redis(...)
    else:
        ...

[DevPatils]

@northdpole please review it once, so that I can proceed.

[northdpole]

Thanks for the clear repro — confirmed, this is a real test-isolation bug (local/dev workflow only; not prod-impacting).

Please proceed, with this constraint on the fix:

• Do: update the affected tests in application/tests/web_main_test.py so they mock the seam the app actually uses — e.g. @patch.object(...redis, "connect") (or equivalently patch StrictRedis / both client constructors). Goal: no real Redis I/O regardless of REDIS_HOST / REDIS_PORT / .env.
• Don't: change application/utils/redis.py connect() production logic just so @patch.object(redis, "from_url") keeps working. That would be the wrong place to fix a test mock mismatch.

Happy to review a PR once the map_analysis Redis-mocked tests are isolated that way.

[DevPatils]

Thanks for the clear repro — confirmed, this is a real test-isolation bug (local/dev workflow only; not prod-impacting).

Please proceed, with this constraint on the fix:

• Do: update the affected tests in application/tests/web_main_test.py so they mock the seam the app actually uses — e.g. @patch.object(...redis, "connect") (or equivalently patch StrictRedis / both client constructors). Goal: no real Redis I/O regardless of REDIS_HOST / REDIS_PORT / .env.
• Don't: change application/utils/redis.py connect() production logic just so @patch.object(redis, "from_url") keeps working. That would be the wrong place to fix a test mock mismatch.

Happy to review a PR once the map_analysis Redis-mocked tests are isolated that way.

Thanks for the review @northdpole, the linked PR solves the issue with keeping constraints in mind. Please review it : )