{
  "id": "rdi-1-19-0",
  "title": "Redis Data Integration release notes 1.19.0 (July 2026)",
  "url": "https://redis.io/docs/latest/integrate/redis-data-integration/release-notes/rdi-1-19-0/",
  "summary": "New redis-di CLI for VM, Kubernetes, and Redis Cloud installations. New Redis sorted set and stream outputs for the Flink processor, expanded Snowflake configuration, and Flink processor support for offline VM installations. Improved pipeline status, secret updates, support packages, and error handling.",
  "tags": [
    "docs",
    "operate",
    "rs"
  ],
  "last_updated": "2026-07-24T10:52:10-07:00",
  "page_type": "content",
  "content_hash": "f37be335177c374aea6953d89e1dda43b44d6b7bc0337d287852f849600c58ab",
  "sections": [
    {
      "id": "what-s-new-in-1-19-0",
      "title": "What's New in 1.19.0",
      "role": "overview",
      "text": ""
    },
    {
      "id": "compatibility-notes",
      "title": "Compatibility Notes",
      "role": "compatibility",
      "text": "- **RDI API v1 deprecated**: RDI API v1 is deprecated as of RDI 1.19.0. Existing API v1 endpoints remain available for backward compatibility, but new integrations should use RDI API v2. API v1 may be removed in a future RDI version. See the [RDI API migration guide](https://redis.io/docs/latest/integrate/redis-data-integration/reference/api-migration).\n- **Unified JSON merge behavior for the Flink processor**: JSON merge behavior is now the same regardless of the target Redis version. Previously, targets without native `JSON.MERGE` support (RedisJSON below 2.6) used a fallback path that preserved null leaf values as JSON nulls, while targets with native support deleted them. Both paths now delete null leaf values. This also differs from the classic processor, which still writes JSON nulls in its fallback path.\n- **`redis/rdi-cli` image and `rdi-secret.sh` retired**: The `redis/rdi-cli` Docker image is no longer built or published, and the `rdi-secret.sh` script has been removed. Manage RDI secrets with the `redis-di` CLI secret commands instead."
    },
    {
      "id": "new-features",
      "title": "New Features",
      "role": "content",
      "text": "- **New `redis-di` CLI**: The `redis-di` command-line tool has been rewritten in Go as a thin client over the RDI REST API. The previous Python CLI talked directly to the RDI Redis database and the Kubernetes API and supported only VM installations; the new CLI works the same way across all installation types: VMs, Kubernetes (Helm), and Redis Cloud. It adds full create/read/update/delete support for pipelines and secrets, new commands for dead letter queues, jobs, and metric collections, and kubectl-style output with optional JSON and YAML formats for scripting. It is multi-pipeline aware, supports both the classic and Flink processors, and authenticates to the API with a JWT (user and password), a Redis Cloud account and user key, or without credentials when API authentication is disabled. The CLI ships as a single self-contained static binary, cross-compiled for `linux/amd64`, `linux/arm64`, `darwin/amd64`, `darwin/arm64`, and `windows/amd64`, and is available from the Redis download center, with the Linux binaries also bundled in the VM installer. The new secret commands replace the `rdi-secret.sh` script, and the `redis/rdi-cli` Docker image is no longer needed (see Compatibility Notes above).\n- **Table-level key and column configuration for Snowflake**: Each table for a Snowflake source now accepts `keys` to select keys and `columns` to project columns.\n- **Snowflake encrypted keypair support**: RDI now supports encrypted Snowflake keypairs for Snowflake sources.\n- **Pipeline metadata `revision` and `tags`**: Pipeline `config.metadata` now accepts an optional `revision` (non-negative integer) and `tags` (array of unique slug-like strings, up to 50 characters each), letting clients mark config states they care about.\n- **Flink processor support for Redis strings and Redis sets**: `redis.write` outputs now accept `data_type: string` and `data_type: set`.\n- **Flink processor support for Redis sorted sets**: `redis.write` outputs now accept `data_type: sorted_set`, using `args.member` and `args.score` to emit `ZADD` and `ZREM` commands.\n- **Flink processor support for Redis streams**: `redis.write` outputs now accept `data_type: stream`, appending each change event to the target stream via `XADD`.\n- **Flink processor images in the offline installer**: The offline VM installation package now bundles the Flink processor and metrics aggregator images, so the Flink processor can be used on such installs. The installer disk space requirement was raised to account for the larger image set.\n- **Per-component replica count in pipeline status**: `GET /api/v2/pipelines/{name}/status` now reports a `replicas` field for each component, giving the number of ready replicas.\n- **Support package covers the Flink processor**: `dump-support-package` now collects Flink processor diagnostics, including per-stream ingest statistics from the counters hash and metrics from the Flink processor ingress.\n- **Operator leader-election mode in API v2 info**: `GET /api/v2/info` now reports the operator leader-election mode (disabled, leader, or follower) in addition to the API version."
    },
    {
      "id": "improvements",
      "title": "Improvements",
      "role": "content",
      "text": "- **Source connection error propagation (\"Test Source\")**: Source database connection failures now propagate through collector-api to the `GET /api/v2/pipelines/{name}/source-schemas/{source}` endpoint with the underlying cause named, instead of a generic error.\n- **Merged Flink processor status**: `GET /api/v2/pipelines/{name}/status` and the metric collection endpoints now report the Flink JobManager and TaskManager as a single `flink-processor` component instead of two separate entries, with status reflecting the worst case of both parts.\n- **Secret updates reflected in pipeline status**: After a source or target database secret is updated, the pipeline reports as not current and non-terminal until every consuming component has restarted with the new secret, so clients can wait for a secret change to take effect the same way they wait for any other change."
    },
    {
      "id": "bug-fixes",
      "title": "Bug Fixes",
      "role": "content",
      "text": "- **Support package log parameters no longer dropped**: Collected component logs now retain their structured key-value parameters (for example, the operator's reconcile context) instead of showing only the timestamp, level, and message.\n- **Pipeline deletion resets state without removing the Pipeline resource**: Deleting a pipeline through API v2 now replaces the Pipeline with an empty inactive configuration and triggers reset cleanup instead of deleting the Kubernetes resource. This avoids unstable operator reconciliation when the operator restarts and removes persisted pipeline runtime data from the RDI database.\n- **Orphaned Redis keys on UPDATE with key change (Flink processor)**: When the key calculated by a custom key expression changes as part of an UPDATE, the Flink processor now removes the entry under the previous key in addition to writing the new one.\n- **Nested JSON outputs ignored `removedFields` on UPDATE (Flink processor)**: Nested JSON outputs (`redis.write` with `data_type: json` and a `nest` block) now apply MongoDB `$unset` removals on UPDATE events, deleting the corresponding top-level and nested fields from the parent JSON document instead of leaving stale values behind.\n- **No RDI API restarts when target database credentials change**: Rotating the target database password or TLS certificates no longer causes the RDI API to restart, eliminating brief request interruptions during credential updates.\n- **Accurate pipeline status during runtime issues**: The pipeline status reported by the API no longer reflects a stale user-requested operation (such as `starting`, `stopping`, or `resetting`) once that operation has completed. Subsequent transitions to `pending` caused by runtime conditions, such as a source database becoming unreachable, are now reported correctly.\n- **Transient deploy-time pipeline errors suppressed**: The pipeline no longer briefly reports a \"Secret provider configuration error\" during deploy while the Secrets Store CSI driver is still mounting volumes. Volume mount warnings are now reported only after the same failure has persisted for at least 30 seconds.\n- **Updating an external secret no longer leaves any component on the stale secret**: Changing an external secret now restarts the affected components so the new secret is mounted, and the pipeline reports `updating` until the restart completes. Previously these components kept the previous secret until restarted for another reason.\n- **Over-counted `incoming` metric across snapshot/Debezium transitions (Flink processor)**: The first record after a snapshot-to-Debezium (or Debezium-to-snapshot) transition was counted twice in the per-stream `incoming` metric; it is now counted once.\n- **Multiline custom snapshot SQL**: A custom snapshot SQL statement containing line breaks (for example, a multi-line `SELECT` entered in the UI) no longer causes saving the pipeline to fail with a server error.\n- **Fixed schema introspection failing for tables/columns with special regex characters in their names**: Table and column names containing Java regex special characters (for example, `emp_1_{06s}`) are now escaped before being written to Debezium's `table.include.list`, `column.include.list`, and `field.exclude.list` properties, which prevented fetching source schema metadata.\n- **JSON target type mismatch left records pending instead of rejected (Flink processor)**: When a JSON target write hit a key that already held a non-JSON value, RedisJSON reported a different error than the classic Redis WRONGTYPE message, so the record was not rejected and the batch stayed pending. The processor now recognizes the RedisJSON variant and rejects the record to the DLQ.\n- **MongoDB oplog checks against managed Atlas tiers**: The MongoDB Debezium oplog size and oplog access checks no longer fail when the source is a managed Atlas tier (such as free or flex) that restricts access to the reserved `local` database. They are skipped and omitted from the validation summary instead of failing, since the connector can still capture changes.\n- **Binary private key secrets corrupted (for example, PostgreSQL PKCS#8 keys)**: Setting a secret from a non-text file, such as a PostgreSQL client key in PKCS#8 DER (`.pk8`) form, no longer corrupts the key. Binary secret files are now base64-encoded end to end through a new `binary_file` secret type; plain text secrets are unaffected."
    }
  ],
  "examples": []
}