No actionable comments were generated in the recent review. 🎉

Summary by CodeRabbit

• New Features

  • Added Redis Sentinel mode configuration support for Redis deployments.

• Chores

  • Updated tool versions and container image tags for classifier, text extractor, and structure tools.
  • Updated sample environment image reference.

Walkthrough

Added Redis Sentinel configuration support by introducing two new environment variables (REDIS_SENTINEL_MODE, REDIS_SENTINEL_MASTER_NAME) and wiring them into constants, runtime/tool environment initialization, and sidecar container configuration. Also bumped several tool image versions and properties.

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR fixes a Redis Sentinel crash in sidecar and tool containers by forwarding REDIS_SENTINEL_MODE and REDIS_SENTINEL_MASTER_NAME env vars to both the tool container (via tools_utils.py::get_tool_environment_variables()) and the sidecar container (via runner.py::_get_sidecar_container_config()). It also bumps version numbers for the classifier, text_extractor, and structure tools across properties.json, public_tools.json, and sample.env.

• Sentinel env vars added to constants: Both runner/constants.py and workflow_execution/constants.py now declare REDIS_SENTINEL_MODE and REDIS_SENTINEL_MASTER_NAME in their respective Env/ToolRuntimeVariable classes.
• tools_utils.py: Reads sentinel vars with raise_exception=False (optional) and forwards them to tool containers with or "False" / or "mymaster" defaults — correct given that create_redis_client() parses the string value with .strip().lower() == "true".
• runner.py: Adds sentinel vars to the sidecar's env dict using os.getenv(..., default). However, the sidecar reads these directly from the runner service's environment, while the tool container receives them from the workflow-execution service's environment (via the envs dict). These are two separate services: if only one is updated with REDIS_SENTINEL_MODE=True, the sidecar will silently revert to standalone mode and reproduce the original crash. The runner's sample.env documents both vars, but there is no programmatic enforcement of consistency between the two sources.
• Tool version bumps: All three tool version increments (classifier 0.0.77, text_extractor 0.0.73, structure 0.0.98) are consistent across properties.json, public_tools.json, and sample.env.

Confidence Score: 4/5

• Safe to merge — non-Sentinel deployments are unaffected by the "False" defaults, and the fix is correct when both services are configured consistently.
• The core fix is logically sound and the create_redis_client() factory correctly interprets the string "True"/"False" values passed as env vars. The main risk is an operational one: the sidecar reads REDIS_SENTINEL_MODE from the runner's own environment while the tool container reads it from the workflow-execution service's environment — two independent sources that must be kept in sync by the operator. A partial upgrade or misconfiguration could silently leave the sidecar in standalone mode and reproduce the original crash. The fix works correctly when both services are fully configured.
• runner/src/unstract/runner/runner.py — the dual-source sentinel configuration between the sidecar and the tool container deserves attention.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant WE as Workflow Execution Service
    participant Runner as Runner Service
    participant Tool as Tool Container
    participant Sidecar as Sidecar Container
    participant Redis as Redis (Sentinel / Standalone)

    WE->>WE: get_tool_environment_variables()<br/>reads REDIS_SENTINEL_MODE from WE env<br/>falls back to "False" via `or` default
    WE->>Runner: run_container(envs={REDIS_SENTINEL_MODE, REDIS_HOST, ...})

    Runner->>Runner: _get_sidecar_container_config()<br/>reads REDIS_SENTINEL_MODE from runner's own os.getenv()<br/>defaults to "False" if not set

    Runner->>Tool: launch with envs[REDIS_SENTINEL_MODE] from WE
    Runner->>Sidecar: launch with runner's os.getenv(REDIS_SENTINEL_MODE)

    Note over Tool,Sidecar: ⚠️ Two independent env sources —<br/>must be configured consistently across both services

    Tool->>Redis: create_redis_client()<br/>_is_sentinel_mode() parses REDIS_SENTINEL_MODE
    Sidecar->>Redis: create_redis_client()<br/>_is_sentinel_mode() parses REDIS_SENTINEL_MODE

    alt Both services have REDIS_SENTINEL_MODE=True
        Redis-->>Tool: Sentinel master connection ✅
        Redis-->>Sidecar: Sentinel master connection ✅
    else Runner env missing REDIS_SENTINEL_MODE=True
        Redis-->>Tool: Sentinel master connection ✅
        Redis-->>Sidecar: Standalone to Sentinel port → "unknown command" ❌
    end

This is a comment left during a code review.
Path: runner/src/unstract/runner/runner.py
Line: 235-238

Comment:
**Sidecar sentinel config is decoupled from tool container sentinel config**

The sidecar's `REDIS_SENTINEL_MODE` is sourced exclusively from the **runner service's own environment** via `os.getenv()`, while the tool container receives it from the `envs` dict populated by the workflow-execution service (via `tools_utils.py`). These are two separate services that must be configured identically for the fix to hold.

If an operator sets `REDIS_SENTINEL_MODE=True` in the workflow-execution service but not in the runner service (or if the runner pod restarts before its env is updated), the sidecar will silently fall back to standalone mode with the default `"False"` — connecting to port 26379 in standalone mode and reproducing the exact `HGETALL`/`SETEX` "unknown command" crash this PR aims to fix.

The same divergence risk exists for `REDIS_HOST` and `REDIS_PORT`, but those are already long-established; adding two more independently-sourced sentinel vars raises the surface area further.

A more defensive approach would be to forward the sentinel values from the already-populated `envs` dict into the sidecar config inside `run_container()`:

```python
# Inside run_container(), before calling _get_sidecar_container_config()
sidecar_config = self._get_sidecar_container_config(
    ...,
    # Pass sentinel vars from the tool envs so both containers use the same source
    sentinel_mode=envs.get("REDIS_SENTINEL_MODE", os.getenv(Env.REDIS_SENTINEL_MODE, "False")),
    sentinel_master_name=envs.get("REDIS_SENTINEL_MASTER_NAME", os.getenv(Env.REDIS_SENTINEL_MASTER_NAME, "mymaster")),
)
```

This would make the sidecar's sentinel mode consistent with the tool container's by design, rather than relying on operational discipline across two independently deployed services.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 73b8216}

Test Results

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