Test cache isolation: FastAPICache.init() no-ops, so the cache leaks between tests

[braddf]

FastAPICache.init() starts with if cls._init: return. The first call in a pytest session wins and every later call is a silent no-op.

Two consequences:

1. _create_server() re-inits the cache per test, but that does nothing after the first test — so the in-memory store is shared for the whole session and a cached route can serve a previous test's response. Hit this while adding coverage for GET /v0/solar/GB/status: the second test got the first one's payload. Existing tests hid it because their second case 404s, and exceptions aren't cached.

2. The ~25 FastAPICache.init(InMemoryBackend(), prefix="test") / prefix="cold" calls in src/quartz_api/internal/service/v1/test_router.py are all no-ops. They neither set the prefix nor provide a fresh backend. The cold-cache 503 tests are not actually starting from a cold cache — they pass on session ordering rather than on the isolation they look like they're asserting.

Fix: autouse fixture in src/quartz_api/internal/service/conftest.py clearing the backend between tests, then drop the no-op init calls in test_router.py.

@pytest_asyncio.fixture(autouse=True)
async def clear_cache():
    if FastAPICache._init:
        await FastAPICache.clear()
    yield

Verified: with this in the shared conftest the full unit suite passes (223 passed) with no exceptions needed — including the v1 cold-cache tests, which get a genuinely cold cache rather than an accidental one. FastAPICache.reset() is also available if a test wants a full re-init.

Interim: test_status_router.py carries a local copy of this fixture. Remove it as part of the fix.

[braddf]

Worth pinning down, since "clear the cache in every test" sounds like it should break the tests that exercise caching:

The fixture clears before each test and then yields. Nothing clears mid-test, so within a single test the cache is fully live — populate on the first call, serve from cache on the second.

Checked this rather than assumed it. A throwaway test against the (now cached) /v0/solar/GB/status route, with the fixture active, issuing two identical requests: upstream was hit once and the second response was the first one's cached body. Passes.

The existing cache-touching tests don't need cross-test state either. The v1 period tests seed their keys inside the test (_set_forecast_meta(), _set_fixed_region_values(), ...) and then read them back, and the cold-cache tests want an empty cache — which is what the fixture actually gives them, unlike the current no-op init calls.

[CodeVishal-17]

I’d like to work on this issue. I can implement the shared "autouse" cache-clearing fixture in "conftest.py", remove the redundant "FastAPICache.init()" calls from "test_router.py", and verify the full test suite along with the cache-specific tests to ensure proper isolation.

If there are no objections, I’ll take this up.

[ocf-bot]

@CodeVishal-17 Thank you for reaching out! Unfortunately, this issue is not suitable for open source contribution and so hasn't been marked with "good first issue" or "contributions welcome". Please consult our contribution guidelines for more information on how you can contribute, and hope to see you around!