[koenmtb1]

Production bug on testnet, found while bringing up the testnet v6 stack.

redis-helper keys every cached response as ${L2_NETWORK_ID}-…. Testnet v5 and testnet v6 now run as separate stacks on one host, both with L2_NETWORK_ID=TESTNET, so their explorer-apis read and write the same cache keys:

• the v6 preview API (api.testnetv6.aztecscan-prod.aztec.foundation) served v5's chain info, rollup-version history and latest block. Only its uncached tips endpoint showed the v6 node's height;
• the public api.testnet.aztecscan.xyz could serve responses cached by the v6 API from its nearly empty database, for up to 60 s (10 s for "latest" endpoints).

#10 isolated Kafka with KAFKA_NAMESPACE but missed Redis. The v6 explorer-api has been stopped on the host until this ships.

Fix

Cache keys start with the deployment namespace from KAFKA_NAMESPACE, the variable that already isolates the stack's Kafka topics and that foundation-iac sets for testnet v6 (v6-TESTNET-…). Unset, as for mainnet and testnet v5, the keys are byte-for-byte unchanged, so existing caches stay valid. No foundation-iac config change is needed; the v6 images just need rebuilding from this commit.

Only explorer-api uses redis-helper. Nothing else in the two stacks is shared by network id alone: Postgres databases are per network key, Kafka is namespaced, and the WebSocket publisher only uses Kafka.

Verification

• New unit tests: unchanged keys without a namespace, distinct keys for two deployments of one network, and namespace validation.
• redis-helper builds and lints. explorer-api builds. yarn test passes across the repo (227 tests).

🤖 Generated with Claude Code