UN-4123 [FEAT] Managed-Redis compatibility: TLS, connection health, and a configurable metrics database

[muhammad-ali-e]

What

Makes an encrypted connection to Redis possible, so the platform can run against a managed endpoint (Memorystore, ElastiCache, Azure Cache — the last of which disables its non-TLS port by default).

The scheme is the switch. {prefix}URL (falling back to REDIS_URL) goes to redis.Redis.from_url, and rediss:// selects TLS on its own — there is no separate "use TLS" flag to forget, and redis:// behaves exactly as today. Discrete host/port vars stay the primary path: they need no percent-encoding, and they are what the Helm chart, every sample.env, and the non-Python services (api-hub, llm-whisperer) read.

Also in scope, because they are the same class of silent failure:

• {prefix}SSL now falls back to REDIS_SSL, plus a CA-certificate option.
• The Django cache and the Socket.IO/kombu manager can finally use TLS (both hardcoded redis://).
• The tool-sidecar and tool-container env allowlists carry TLS settings and REDIS_DB.
• health_check_interval defaults to 30s.
• The sdk1 metrics database is now configurable (METRICS_REDIS_DB), which is what makes a single-database endpoint reachable — see below.

Why

Password-only auth to an external Redis already worked, so TLS was the missing half. Chart-side support for pointing at an external endpoint is UN-4122 (cloud repo); this is the OSS half.

Everything is additive and inert by default — with nothing configured, the local/in-cluster path builds exactly the client it built before.

Two redis-py behaviours bite silently, and both are now handled and pinned by tests:

1. The URL path beats a db= kwarg. from_url('rediss://h:6380/5', db=1) yields db 5. sdk1 metrics asks for db=1 explicitly, so a URL carrying a path would have moved its keys into another service's keyspace with nothing to indicate it. The path is stripped when an override is given.
2. ssl=True into a ConnectionPool does not fail at construction. The pool defers its kwargs to the connection class, so platform-service (max_connections=10) started healthy, kept the plain Connection class, and raised TypeError: AbstractConnection.__init__() got an unexpected keyword argument 'ssl' on its first command. Pooled TLS now selects SSLConnection.

Three more silent failures fixed:

• A forgotten per-prefix SSL flag is a plaintext client dialling a TLS port. CACHE_REDIS_SSL and MANUAL_REVIEW_REDIS_SSL had to be set separately; they now inherit REDIS_SSL and can still override it.
• django-redis 5.4.0 ignores DB and USERNAME from OPTIONS. Verified against the installed version — ConnectionFactory.make_connection_params reads only PASSWORD and the two timeouts; DB: 3 yields db=None, while redis://h:6379/3 yields db=3. The db now travels in the LOCATION URL, so the backend cache stops sitting on db 0 while every other service honours REDIS_DB: with REDIS_DB=N, workers RPUSH log_history_queue to db N and the backend LPOPs an empty db 0. USERNAME is deliberately not restored — auth stays password-only as the built-in default user, which is what a managed AUTH string is; named ACL users cannot work platform-wide while django-redis discards the username.
• kombu reads TLS off the scheme but defaults ssl_cert_reqs to CERT_NONE — encrypted while accepting any certificate. The Socket.IO manager URL now carries an explicit ssl_cert_reqs, since KombuManager takes a URL rather than connection kwargs.

Single-database endpoints

A whole class of managed Redis exposes db 0 only: Azure Managed Redis, Redis Enterprise / Redis Cloud, and every cluster-mode service (ElastiCache and Memorystore included). Unstract used dbs 0, 1, 5 and 8, so those tiers were out of reach.

MetricsMixin hardcoded create_redis_client(db=1) — after a sweep of every create_redis_client() call site, the only place left in the codebase that chose a database in code rather than in configuration. (backend/utils/cache_service.py:71 looks like a second one but already takes db as a parameter.)

METRICS_REDIS_DB defaults to 1, the value that was hardcoded, so an unset var leaves every existing deployment byte-identical. A single-database deployment sets it to 0 alongside CACHE_REDIS_DB and FILE_ACTIVE_CACHE_REDIS_DB — those three are the whole of Unstract's on-prem map, since dbs 5 and 8 belong to api-hub and the llm-whisperer portal, both cloud-only. Multi-database stays the default and needs no configuration at all.

Read per instance rather than once at import, so a malformed value raises inside __init__'s existing try/except — costing the metric — instead of killing the process at import time.

The tool-container allowlist carries the key; the sidecar allowlist deliberately does not, because the sidecar publishes logs and never imports sdk1. Without the first, the setting would apply everywhere except the containers doing the work — the same partial, silent failure as the LOG_TRANSPORT allowlist miss in UN-3755.

Worth knowing: against a db-0-only endpoint today, this does not crash. redis-py connects lazily, so SELECT 1 fails on the first command inside the existing try/except — you lose the time-taken metric and gain error noise. So this converts a degraded state into a clean one rather than fixing an outage.

How

# either
REDIS_SSL=true
REDIS_SSL_CERT_REQS=required
REDIS_SSL_CA_CERTS=/etc/ssl/redis-ca.pem   # only where the CA isn't publicly trusted (Memorystore)

# or
REDIS_URL=rediss://:<password>@<host>:6380/0?ssl_cert_reqs=required

For a single-database endpoint, move the whole map together:

CACHE_REDIS_DB=0
FILE_ACTIVE_CACHE_REDIS_DB=0
METRICS_REDIS_DB=0

CACHE_REDIS_DB and FILE_ACTIVE_CACHE_REDIS_DB must always match — the workers write file_active:* to one and the backend reads them from the other. Splitting them stops active-file dedup finding anything, with no error and no log; every file is reprocessed as new. The chart-side PR fails the render on a mismatch.

health_check_interval defaults to 30s ({prefix}HEALTH_CHECK_INTERVAL, 0 disables). Only the two worker caches set it before, so a connection killed while parked — managed failover, or Azure Cache's 10-minute idle reaper — was discovered by a real command failing on it. This applies with or without TLS.

Retries are deliberately not enabled globally. retry_on_timeout would re-issue blocking BLPOP/BLMOVE calls whose reply was lost, risking consuming a second message rather than recovering the first — the trap already documented at pg_queue/result_backend.py:152.

Can this PR break any existing features. If yes, please list possible items. If no, please explain why.

No. Every new setting is opt-in and the default path is unchanged — the first test in the new suite pins plaintext/localhost/db0 with no SSL kwargs.

Two intentional behaviour changes on the existing path, both called out for review:

1. health_check_interval now defaults to 30s instead of 0. Effect: redis-py sends a PING before reusing a connection idle longer than that. Set REDIS_HEALTH_CHECK_INTERVAL=0 to restore the old behaviour.

2. The Django cache LOCATION now carries the db path. For REDIS_DB unset or 0 — every shipped config — the connection is identical. Where REDIS_DB=N, the backend cache moves from db 0 to db N, which is the fix described above; that deployment is currently split-brained with its own workers.

3. METRICS_REDIS_DB defaults to 1 — the literal it replaces. No shipped config sets it, so every deployment resolves to the same database on the same line.

Sidecar/tool env keys are forwarded only when set, so an unconfigured deployment sees no new variables.

Database Migrations

None.

Env Config

All optional, all defaulting to current behaviour: REDIS_URL / {prefix}URL, REDIS_SSL, REDIS_SSL_CERT_REQS, REDIS_SSL_CA_CERTS, REDIS_HEALTH_CHECK_INTERVAL, METRICS_REDIS_DB. Documented in backend/, runner/, platform-service/ and workers/ sample.env.

Relevant Docs

Module docstring in unstract/core/.../cache/redis_client.py covers URL-vs-discrete precedence and why discrete stays primary.

Merge order — this PR goes FIRST

Merge this before unstract-cloud#1774. The two ship as a pair, and the chart depends on a fallback added here.

#1774 stops rendering CACHE_REDIS_SSL into the worker ConfigMap (a rendered literal shadows the real value when REDIS_SSL arrives from an existingSecret or ESO). That is only safe because this PR makes _resolve_redis_env fall back {prefix}SSL → REDIS_SSL. On main today there is no fallback:

ssl = os.getenv(f"{env_prefix}SSL", "false").strip().lower() == "true"

so the chart landing first would leave the worker cache alone on a plaintext connection whenever TLS is enabled — degraded to no-cache with only a warning, nothing failing loudly.

Nothing in this PR depends on the chart, so it is safe to merge on its own.

Related Issues or PRs

UN-4123. Pairs with UN-4122 (cloud chart: external/managed Redis endpoint).

Not covered here, tracked separately: api-hub builds a credential-free redis:// URL and needs a one-line fix before AUTH is enabled anywhere, and llm-whisperer supports a password but has no TLS support. Both live in their own repos.

Dependencies Versions

No changes. Behaviour verified against the pinned redis-py 5.2.1, kombu 5.5.4, django-redis 5.4.0.

Notes on Testing

Automated

Suite	Count	Notes
unstract/core/tests/	237	100 in test_redis_client_config.py
backend/backend/tests/test_redis_settings_derivation.py	35	execs three slices of the shipping settings/base.py, not a copy
unstract/sdk1/tests/test_metrics_redis_db.py	7	patches the client factory — no live Redis, no stray keys
runner/tests/test_sidecar_log_transport.py	10

CI on the PR: unit-core 237, unit-sdk1 587, unit-backend 1318, unit-workers 1362, integration-backend 598, all e2e groups — green.

Every fix in the last two review rounds is mutation-verified: each one reverted individually, each caught by a named test. That matters because the round before found three tests that could not fail — including one that fed the Critical's exact input and passed, and a drift guard that missed the variable its own commit introduced.

Pre-existing CI failures, not from this PR: integration-workers (5) and frontend/ui (1 each). The workers failures are all psycopg2.OperationalError: could not translate host name "unstract-db" in test_pg_barrier.py — PG-queue code, Postgres DNS. Confirmed repo-wide: PRs #2295 and #2293 show identical counts in the same groups, and a docs-only commit here reproduced them exactly.

Live — ali-unstract-dev, GCP Memorystore

Deployed via dev-deploy (snapshot.326) with the chart from Zipstack/unstract-cloud#1774.

Scenario	Result
Managed Redis, discrete REDIS_HOST/PORT/PASSWORD	✅ execution completed, keyspace verified
Managed Redis, REDIS_URL	✅ same
TLS — rediss://…:6378/0?ssl_cert_reqs=none	✅ the Critical, against a real endpoint
Non-default port (6378) derived from the URL	✅ reached all 27 init containers, CACHE_REDIS_*, HITL
Single-database collapse — all four keys to db 0	✅ worker_cache, logs, log_history_queue, metrics all on db0
Revert to the default multi-database layout	✅ split restored, db0 + db1
Django cache follows the database rule	✅ django.contrib.sessions.cached_db… on db0

The TLS run is the one that matters. Before 418e78b5d, that URL produced ssl_check_hostname=true injected beside the URL's CERT_NONE, and ssl.SSLContext raises on that pair — every client, every process, at first command. Live: no such error, and api_results, logs, execution, log_history_queue and file_execution all landed on the Memorystore instance over TLS. api_results is the specific silent failure this PR's description opens with.

NOT tested — read this before relying on it

• Sentinel + TLS. The highest real-world-risk fix in this PR (masters get hostname verification against the IP Sentinel returns, which no DNS SAN covers). Verified from redis-py source and pinned by unit tests; no live Sentinel deployment exists to run it against.
• TLS with ssl_cert_reqs=required against Memorystore. Blocked, and known: Memorystore's CA is Google-private and the chart mounts no CA into any pod. ElastiCache and Azure Cache chain to public CAs and are unaffected. A CA-mount is follow-up work, not part of this PR.
• The container-based tool path. Every execution above ran the structure tool, which runs in-process, so no tool container or sidecar was spawned. The allowlist forwarding is asserted by tests (now against the forwarding tuples, not just the constants) but not exercised end to end. One classifier or text_extractor run would close it.
• file_active:* and metrics:* at rest. Both are transient by design — file_active exists only during a file's processing, and collect_metrics() deletes its key on completion. metrics was observed on db0 mid-flight during the single-DB run; neither was observable after completion.

🤖 Generated with Claude Code

[greptile-apps]

via Greptile

Confidence Score: 5/5

The PR appears safe to merge; all previous findings are resolved and the post-review documentation changes introduce no actionable issue.

Summary

This PR adds managed-Redis compatibility across backend, worker, runner, and SDK Redis consumers.

• Supports TLS through discrete settings or rediss:// URLs, including CA and hostname verification.
• Centralizes Redis URL, database, and Socket.IO/Kombu derivation.
• Adds configurable metrics Redis database selection and forwards Redis settings into tool containers and sidecars.
• Adds connection health checks, configuration documentation, regression tests, and a local TLS Redis environment.
• The changes since the previous review only clarify that port 6380 is provider-specific; no new correctness issue was identified.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Env[Redis environment settings] --> Resolver[Shared Redis configuration helpers]
  Resolver --> Core[redis-py clients]
  Resolver --> Django[Django cache]
  Resolver --> SocketIO[Socket.IO / Kombu]
  Env --> Runner[Runner allowlists]
  Runner --> Tools[Tool containers and sidecars]
  Env --> Metrics[SDK metrics client]

Loading

_{Reviews (10) · Last reviewed commit: "UN-4123 [DOCS] The TLS port is provider-..."}

[muhammad-ali-e]

Standardized PR Review — FOLLOWUP

Verdict: REQUEST CHANGES

Summary — Critical: 0 · High: 3 · Medium: 13 · Low: 6 · Lenses run: 16/16

Reviewed under unstract plugin v0.18.1 · head 3690a07ff · base 53269a1fc.

This is a careful, well-evidenced PR — the reasoning in the comments is better than most, the tests assert on real connection objects rather than mocks, and the two redis-py traps it documents both reproduce exactly as described. Nothing here breaks an existing deployment: the default path is genuinely inert. What holds it up is that the TLS it introduces does not authenticate the server, and that ssl_cert_reqs is resolved three different ways, so half the platform ignores the operator's setting — including in the dev recipe this PR ships to verify the work.

Prior context fetched

All six gh calls ran clean. My 6 prior reviews / 6 inline comments on this PR are all replies acknowledging Greptile's findings — none asserts a problem of my own, so by the prompt's parsing rules I carry zero prior findings into this run. There is therefore no status table. Greptile's six P1/P2s are another reviewer's ledger; I spot-checked them and all six are genuinely fixed at the current head, but I do not mark them resolved on that reviewer's behalf.

Since-boundary: my last replies were at 62b0224b7; 14d38c4a3 and 3690a07ff landed after.

Scope change

YES — 14d38c4a3 added the METRICS_REDIS_DB feature after my last pass: a new public helper, a new env var, a new test file, and a new key in the tool-container allowlist. New surface, so all 16 lenses were run over the whole diff rather than a targeted re-check.

How this was verified

Every third-party behavioural claim below was executed against the pinned packages (redis-py 5.2.1, kombu 5.5.4, django-redis 5.4.0), not recalled. Two of the PR's own load-bearing claims — the URL path beating a db= kwarg, and ssl=True into a ConnectionPool raising only on first command — reproduce exactly as documented.

I also rejected a proposed finding that Sentinel+TLS raises TypeError: redis-py's SentinelConnectionPool pops ssl and selects SentinelManagedSSLConnection itself, so the master path is fine. The real Sentinel issue is narrower and is finding #9.

Lens checklist

#	Lens	Result
1	Spec & intent	See #6, #12
2	Architectural fit & precedent	See #11, #8
3	Correctness & edge cases	See #2, #7, #10
4	Security	See #1, #9
5	Data integrity & migrations	See #6 (assessed by me)
6	Concurrency	Clean (assessed by me — the health-check PING precedes the command; the blocking BLPOP/BLMOVE socket-timeout contracts at result_backend.py:188 and redis_stream_consumer.py:56 are unaffected)
7	API & contract compatibility	See #2, #5
8	Reliability & resilience	See #10, #12 (assessed by me)
9	Performance & cost	Clean — one extra PING per connection idle past 30s (assessed by me)
10	Observability	See #7, #8
11	Operational safety	See #6, #8, #12 (assessed by me)
12	LLM/agent	N/A — touches sdk1 plumbing only; no prompts, model config, or tool-call paths (assessed by me)
13	Testing	See #16 (assessed by me)
14	Dependencies & build	Clean — no dependency changes (assessed by me)
15	Code quality	See #11
16	Doc & comment accuracy	See #3, #4, #13, #14, #15

Low findings (not individually anchored)

• redis_client.py:71-79 — _strip_url_db_path blanks the socket path of a unix:// URL, and does not strip a ?db= query param, which redis-py also honours over a db= kwarg. The docstring's "lets the explicit argument apply" is true only for the path form.
• redis_client.py:45-46 — "30s is redis-py's own documented recommendation" is unsupported: redis-py 5.2.1's own default is 0 and the shipped distribution carries no such recommendation. (The companion claim, that 0 is what every client except the two worker caches used before, does check out.)
• redis_client.py:154-156 — "KombuManager takes a URL, not connection kwargs" is false; it accepts connection_options, and workers/log_consumer/tasks.py:65-72 passes them in the Sentinel branch.
• redis_client.py:8-13 — the module docstring says a URL "overrides the discrete host/port/credential vars" with no qualification, but Sentinel mode never reads it (build_socketio_redis_url's own docstring scopes itself correctly at :164-165).
• redis_client.py:120-122 — health_check_interval=0 changed from "disabled" to "unset" on a public shared-library function, so a caller can no longer disable it through the API. Latent: no in-repo caller passes 0 today. int | None = None would keep 0 meaning zero.
• redis_client.py:205 — int(os.getenv(f"{prefix}PORT", ...)) now runs during Django settings import via build_socketio_redis_url, so a set-but-empty REDIS_PORT="" (a blank ConfigMap key) fails the backend at boot rather than at first use.

Open questions

1. integration-workers reports 5 failures in the CI summary table while the gating jobs are all green. Known-flaky, or worth a look before merge?
2. Is hostname verification (#1) something you want on by default, or opt-in behind {prefix}SSL_CHECK_HOSTNAME?
3. The PR notes the container-based tool path is still unproven end to end. Findings #8 and #12 both live on that path — worth doing that classifier/text_extractor run before this is relied on.

Assumptions

• The chart points every Redis prefix at the same host — verified: all *_REDIS_HOST values are unstract-platform-redis-master. That is what keeps #5 at Medium rather than High.
• No shipped config sets a non-zero REDIS_DB for the backend, which keeps #6 a deploy note rather than a live break.

[muhammad-ali-e]

Addendum to the standardized review — lens 13 (Testing)

Revised verdict: REQUEST CHANGES — Critical: 0 · High: 5 (was 3) · Medium: 13 · Low: 8

My main review noted that lens 13 was assessed by me directly because the test-analysis pass had not finished. It has now, with mutation-verified results that change the picture, so I am correcting the record rather than leaving the earlier read to stand.

Two new High findings are inline below. Both were proven by mutating the shipping source and re-running the suite — not by reading it:

1. test_redis_settings_derivation.py executes a source slice that excludes all four variables this PR adds, testing a hand-written copy of them instead — which is precisely what its own docstring says the approach avoids.
2. Discrete-mode cache credentials are never asserted; dropping the Redis password leaves the suite green.

What this does not change

My earlier assessment of unstract/core/tests/test_redis_client_config.py stands, and was independently mutation-tested: three of the four regressions you say are pinned genuinely are — removing _strip_url_db_path fails 3 tests, removing the connection_class swap fails test_pooled_tls_client_is_usable, removing the ssl_cert_reqs injection fails 2. The fourth (django-redis ignoring DB/USERNAME) is the one with no executable assertion — finding #2 above. test_metrics_redis_db.py also pins the wiring, not just the helper: reverting metrics_mixin.py:47 fails all three parametrised cases.

No test was deleted or weakened anywhere: git diff -- "*test*" is 4 files, 567 insertions, zero deletions.

Additional Medium/Low, not separately anchored

• unstract/workflow-execution/.../tools_utils.py:243-258 — the tool-container allowlist has no tests at all, and its package has no unit group in tests/groups.yaml (only an optional: true placeholder pointing at a directory that does not exist). Its structural twin, the sidecar allowlist, got five tests. This is the untested half of finding #8.
• workers/log_consumer/tasks.py:59 — nothing asserts the worker actually calls build_socketio_redis_url; workers/tests/test_log_stream_consumer.py:61 stubs the module into sys.modules, so reverting that line to a hand-built f-string is caught by no test in the repo. That is the anti-drift fix's own half.
• No test asserts SOCKET_IO_MANAGER_URL at all, though _derive() already returns it. One line — assert urlsplit(SOCKET_IO_MANAGER_URL).netloc == urlsplit(LOCATION).netloc — would encode the PR's actual premise.
• unstract/sdk1/tests/test_metrics_redis_db.py:36 constructs a real client with no env isolation, unlike the core suite's autouse _clean_redis_env. With REDIS_SENTINEL_MODE=true in the ambient shell it enters the 10-attempt backoff and does real DNS for ~7 minutes. (I hit this myself while probing.) Copy that fixture over.
• TLS is never exercised over a real socket in any CI tier. docker-compose-redis-tls.yaml makes the live run reproducible but leaves it manual — and --port 0 in that overlay already guarantees a service that misses the settings cannot quietly succeed, which makes it a good e2e-redis-tls target. Worth a follow-up ticket rather than this PR.
• _derive() pins itself to two source strings via str.index (reordering base.py turns every test into a collection-time ValueError) and mutates os.environ by hand rather than via monkeypatch, so an interrupt inside exec leaves the session stripped of every REDIS_* key.
• Surviving mutants in redis_client.py: the max(int(raw), 0) clamp at :60 (mutating to int(raw) leaves all 35 green), the prefix-scoped {prefix}HEALTH_CHECK_INTERVAL lookup at :56, and build_socketio_redis_url's username+password branch at :176-180 — each verified working today, none pinned.

Correction I am holding to

A Sentinel + TLS TypeError was proposed again in this pass. I am rejecting it again: redis-py 5.2.1's SentinelConnectionPool.__init__ does kwargs.pop("ssl", False) and selects SentinelManagedSSLConnection itself, which I executed. The master path is fine. The real Sentinel gap is the plaintext discovery connection in finding #9 of the main review, and the absence of any Sentinel test — which stands.

[muhammad-ali-e]

Standardized review — FOLLOWUP round 3

Range: 3690a07ff..86162020c · Agents: code-reviewer, silent-failure-hunter, pr-test-analyzer, comment-analyzer · Verdict at time of review: BLOCK — 1 Critical, 10 High.

All of it is now fixed in 418e78b5d, which is pushed. Posting the findings anyway, because the pattern in them matters more than the individual bugs.

The pattern

Nearly every finding this round was introduced by the previous round's fixes. Round 2 closed 17 review findings in 10 commits; this review found 11 blocking defects, and roughly nine of them are in lines those commits added. The shape is consistent: the diagnosis was right, the fix was applied at one site, and the identical defect was left standing at the next one.

• ssl_cert_reqs was resolved once — from the env, never from the URL's query string.
• blank-means-unset was established as a convention in 178f1c70b — and REDIS_SSL_CHECK_HOSTNAME, added in that same commit, used a bare == "true".
• the database rule was unified in 5f8a567ad — in unstract.core, not in the Django cache LOCATION beside it.
• a drift guard was added in 86162020c to catch exactly this — and it omitted the variable the same commit introduced, and asserted the constants file rather than the tuple that actually reaches the container.

The tests did not catch any of it because they asserted presence rather than correctness. test_an_explicit_cert_reqs_in_the_url_is_respected feeds the Critical's exact input and passes. Deleting the guard it tests left all 76 tests green. That was only discovered by mutating the source, which no earlier round did.

Critical

A URL carrying ?ssl_cert_reqs=none got ssl_check_hostname=true appended beside it. ssl.SSLContext raises Cannot set verify_mode to CERT_NONE when check_hostname is enabled — so this is not a weakened connection, it is no connection, on every Redis client in the process, at the first command rather than at startup. Reproduced end to end on all three consumers (client kwargs, Socket.IO URL, django-redis LOCATION). docker/redis-tls/README.md documents that URL form as supported.

High

#	Finding
H1	The database rule reached create_redis_client but not base.py's cache LOCATION — one REDIS_URL + one REDIS_DB resolving to two databases; workers RPUSH log_history_queue to db N, backend LPOPs an empty db 0, silently
H2	The generic REDIS_DB crossed into a prefix that brought its own URL. workers/sample.env ships REDIS_DB=0 uncommented, so CACHE_REDIS_URL=…/1 landed on db 0
H3	REDIS_SSL_CHECK_HOSTNAME — the only escape hatch for the new on-by-default verification — reached neither container allowlist, no sample.env, and was absent from the drift-guard set
H4	Blank REDIS_SSL_CHECK_HOSTNAME= read as False, inverting this PR's own convention. So did =1 and =yes
H5	Blank {prefix}SSL_CERT_REQS resolved three ways in one process: hard RedisError on the discrete client, silent CERT_NONE on the kombu URL, required on the URL path
H6	Sentinel + TLS regression. _tls_kwargs set ssl_check_hostname=True on master connections, which reach the IP SENTINEL get-master-addr-by-name returns — SentinelManagedConnection.connect_to assigns it to self.host, SSLConnection passes it as server_hostname. Every existing REDIS_SENTINEL_MODE + REDIS_SSL deployment would have failed on upgrade, through the full ten-attempt backoff
H7	The drift guard asserted the constants declaration, not the forwarding tuple. Deleting Env.REDIS_HEALTH_CHECK_INTERVAL from runner.py — the exact omission it was written for — left the suite green
H8	base.py's URL-mode TLS query was entirely untested; setting check_hostname=None kept CI green while restoring redis-py's unauthenticated default
H9	test_metrics_stay_enabled_through_a_bad_value was vacuous (redis_key is assigned unconditionally after the try/except, so it passed under the pre-fix code) and wrote 24h-TTL keys to whatever REDIS_URL the shell exported — 41 real keys found on a local db
H10	The TLS README's two-database recipe could not work: the shipped REDIS_DB=0/CACHE_REDIS_DB=0 defeat the /1 it says "matters", producing verbatim the dedup split its own paragraph warns about

Plus 12 Medium (blank {prefix}DB escaping as a bare ValueError; a dead cert_reqs fallback; four docstrings contradicting their code, two of which I had already corrected in sample.env but not in the source) and 3 Low.

What changed structurally, so this stops recurring

1. One resolution point per setting, reading the URL as well as the env — effective_cert_reqs(), resolve_ssl_cert_reqs(), resolve_ssl_check_hostname(), set_url_db_path() / url_db_path(), all exported and used by base.py instead of it re-implementing them.
2. The guard is derived, not listed. _SHARED is regexed out of redis_client.py with an explicit list of deliberate exclusions, so the next variable added to the module fails a test rather than needing a third hand-maintained list to be remembered. A second test asserts the forwarding tuples.
3. Every fix is mutation-verified — 11 mutations, each reverting one fix, each caught by a named test. Tests: core 57 → 91, backend 15 → 30.
4. The backend harness splices base.py's real import block as a third source slice instead of hand-listing it, and sets __name__ so the relocation warning is reachable at all.

One of my own fixes had a bug, caught by the first test I wrote for it: the relocation warning compared REDIS_DB against the URL's path, so a plain redis://h/3 with no REDIS_DB announced a data-loss move that never happens. Both sides now compare the effective db.

Prior findings

All 17 from rounds 1-2 remain RESOLVED, each with its fixing commit in-thread. None waived, none dropped.

Lens checklist

1 Spec See C1, H1 · 2 Architecture See H1 · 3 Correctness See C1, H1-H5 · 4 Security See C1, H4, H5, H8 · 5 Data integrity See H1, H2 · 6 Concurrency Clean (assessed by me) · 7 API/contract See H3 · 8 Reliability See H6 · 9 Performance Clean (mine) · 10 Observability See H4 · 11 Operational safety See H3, H6 (mine) · 12 LLM/agent N/A — no model calls · 13 Testing See H7-H9 · 14 Dependencies Clean (mine — no dep changes) · 15 Code quality Medium only · 16 Doc accuracy See H10 + 6 Medium

One agent disagreement, resolved

code-reviewer marked the Sentinel path clean; silent-failure-hunter called it a regression. They checked different things — the former verified master_for selects SentinelManagedSSLConnection rather than raising TypeError (true, and clean); the latter checked hostname verification against the discovered IP. H6 stands; I verified the redis-py mechanics from source directly.

[muhammad-ali-e]

Scoped review of 418e78b5d — no Critical, no High

Re-reviewed only 86162020c..418e78b5d (the commit that fixed the previous round's 11 findings), aimed squarely at the failure mode that produced the last three rounds: a correct diagnosis applied at one site while the identical defect stands at the next one.

First round in four where the previous round's fixes introduced no blocking defect. Three Mediums and three Lows, all fixed in 6ba80376a.

What it found — and the one that matters

parse_db was introduced with a docstring explaining why int(os.getenv(...)) on a database var kills the process at import — and three sites in settings/base.py still did exactly that, with the same variables. So the two halves disagreed on a malformed value: workers warn and continue on db 0, the backend refuses to start. That is the series' recurring shape, one more time. Now shared.

FILE_ACTIVE_CACHE_REDIS_DB sits ~350 lines above the derivation block, outside both slices the exec harness runs, so no _derive() case can reach it. Pinned by a source check instead — which covers all three sites at once, because the defect was never one line, it was one expression repeated wherever a database var is read.

The forwarding guard I tightened last round was still too loose. It asserts the tuple rather than the constants declaration — correct — but searched the whole file text, so commenting out a tuple entry passed. Same "present somewhere ≠ present where it matters" weakness, one level down. It now slices the tuple's own region and drops commented lines.

All three sample.env files displayed # REDIS_SSL_CHECK_HOSTNAME=true — and an explicit value is honoured on Sentinel master connections, so uncommenting that line silently breaks exactly the deployments the new default was added to protect. They now show false, the only value worth setting.

Coverage

core 91 → 100, backend 30 → 35. Seven mutations verified, including one that initially survived: parse_db's own .strip() is unreachable through create_redis_client (_resolve_redis_env strips first), so the assertion pinning it had to move to the backend suite, which reads REDIS_DB raw. Found by mutation, not by reading.

Verified sound, so it is not re-investigated

Backend/core database parity across six env shapes; the chart's exact shape (inherited REDIS_URL, CACHE_REDIS_DB: "1", no CACHE_REDIS_URL) still resolving to db 1; set_url_db_path boundaries including pathless, trailing-slash, query, fragment and @ in credentials; Sentinel without TLS byte-identical; db= override from sdk1 metrics still winning; the _SHARED regex against all 25 os.getenv call sites.

Chart-side counterpart is Zipstack/unstract-cloud#1774 (fa3b0ec0), which declares REDIS_SSL_CHECK_HOSTNAME and fixes an on-prem example this PR's new default had broken. Merge order: this PR first. Neither is merging before the testing round.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Unstract test results

Per-group results

Status	Group	Tier	Passed	Failed	Errors	Skipped	Duration (s)
✅	e2e-api-deployment	e2e	3	0	0	0	19.5
✅	e2e-coowners	e2e	1	0	0	0	1.4
✅	e2e-etl	e2e	1	0	0	0	14.5
✅	e2e-login	e2e	2	0	0	0	1.4
✅	e2e-prompt-studio	e2e	1	0	0	0	5.7
✅	e2e-smoke	e2e	2	0	0	0	2.2
✅	e2e-workflow	e2e	1	0	0	0	20.5
❌	frontend	unit	0	1	0	0	0.0
✅	integration-backend	integration	598	0	0	26	57.6
✅	integration-connectors	integration	1	0	0	7	8.1
❌	integration-workers	integration	159	5	0	1	55.8
❌	ui	e2e	0	1	0	0	0.0
✅	unit-backend	unit	1318	0	0	1	46.0
✅	unit-connectors	unit	63	0	0	0	9.8
✅	unit-core	unit	237	0	0	0	3.0
✅	unit-platform-service	unit	15	0	0	0	2.6
✅	unit-rig	unit	120	0	0	0	4.7
✅	unit-runner	unit	10	0	0	0	3.0
✅	unit-sdk1	unit	587	0	0	0	32.2
✅	unit-workers	unit	1362	0	0	1	126.5
	TOTAL		4481	7	0	36	414.5

Critical paths

⚠️ Critical paths not yet covered

• workflow-execution-fan-out — Multi-file workflow execution fans out to file-processing workers and rejoins. (declared coverage: no groups declared)

✅ Covered critical paths

• auth-login — covered by e2e-login
• adapter-register-llm — covered by integration-backend
• workflow-author — covered by integration-backend
• co-owner-manage — covered by integration-backend, e2e-coowners
• workflow-create-execute — covered by e2e-workflow
• api-deployment-provision — covered by integration-backend
• api-deployment-auth — covered by integration-backend
• api-deployment-run — covered by e2e-api-deployment
• mcp-server-auth — covered by integration-backend
• mcp-platform-auth — covered by integration-backend
• platform-key-whoami — covered by integration-backend
• prompt-studio-author — covered by integration-backend
• prompt-studio-fetch-response — covered by e2e-prompt-studio
• connector-register-test — covered by integration-backend
• pipeline-etl-execute — covered by e2e-etl
• usage-aggregate-read — covered by integration-backend
• usage-token-tracking — covered by e2e-api-deployment
• callback-result-delivery — covered by e2e-api-deployment