Redis Data Integration release notes 2.2.0 (October 2026)

Named pipelines, pipeline configuration export, Snowflake connection discovery, expanded secret references, and high-availability and security improvements.

What's New in 2.2.0

Breaking Changes

See Upgrading to RDI 2.2.0 for the breaking changes and the steps to take before and after you upgrade.

A fresh installation no longer creates an empty default pipeline. Create a pipeline before using its endpoints. See Deploy a pipeline.

New Features

• Export a pipeline configuration with redis-di export: Use redis-di export [pipeline] --dir <dir> to write the configuration of a deployed pipeline to config.yaml and jobs/*.yaml, ready to edit and deploy again with redis-di deploy --dir <dir>. See redis-di export.
• Write records to RDI streams with external sources: Set the type of a source to external when another producer writes records directly to the RDI streams. RDI deploys no collector and needs no database connection for such a source, and it still validates the source's jobs. External sources require the Flink processor.
• Test Snowflake connections and browse database metadata: You can test a Snowflake connection and browse its schemas, tables, and columns while setting up a source, before starting replication.
• Store any connection parameter in a secret: RDI accepts any secret key made of uppercase letters, digits, and underscores that starts with a letter, in addition to USERNAME, PASSWORD, CACERT, CERT, KEY, and KEY_PASSWORD. Set the key with redis-di set-secret <key> --db <source|target> or through the API v2 secret endpoints. Reference it from config.yaml as ${<DB>_DB_<KEY>}. Pass --type file to store the value as a file, such as an additional CA certificate; the reference then resolves to the path of the mounted file.
• Use names other than default for pipelines: POST /api/v2/pipelines, PUT /api/v2/pipelines/{name}, and redis-di deploy <name> accept a name of 3 to 20 characters that starts with a lowercase letter, ends with a letter or a digit, uses only lowercase letters, digits, and dashes, and contains no consecutive dashes. The name rdi is reserved. Each pipeline gets its own components, secrets, and secret provider resources. Finish upgrading all instances before creating a pipeline, and do not downgrade after creating one. The ingress and metrics paths of a pipeline other than default start with the pipeline name, for example /orders/processor/metrics, or /orders/metrics-exporter/metrics for the classic processor on a VM installation. The ServiceMonitors of the collectors and the stream processors add a pipeline label with the pipeline name, and the classic processor metrics exporter reports the metrics of its own pipeline. See Multiple pipelines in one RDI installation.
• Delete pipelines with redis-di delete: The command deletes a pipeline, its components, and its RDI database keys while keeping its secrets. Unless you pass --wait=false, it waits for the pipeline to disappear or fails after --timeout.
• See configuration references for secrets: API v2 pipeline secret endpoints and the redis-di CLI report a config_reference field. The CLI shows it as the CONFIG REFERENCE column of list-secrets and get-secret, and as the Config Reference field of describe-secret. Use it as the placeholder for the secret in config.yaml, for example ${MYSQL_DB_USERNAME}.
• Trigger manual failover through the API or CLI: Set standby_mode with redis-di set-setting standby_mode true or PATCH /api/v2/settings to remove an instance from leader election. Restore the previous setting after maintenance; deleting it restores the Helm default. Runtime standby_mode overrides operator.leaderElection.standbyMode. Use redis-di list-settings or GET /api/v2/settings to inspect the settings. Changing a setting does not restart the RDI operator or API. See RDI instance settings and Trigger a failover manually.

Bug Fixes

• Report Snowflake connection errors as validation failures: Known authentication and connection failures during metadata discovery now return HTTP 422 with an authentication or connection label instead of HTTP 502, while preserving the detailed error message.
• Report duplicate source properties clearly: Requests containing both prefixed and unprefixed versions of a Debezium source property now return a validation error without exposing property values instead of an internal server error.
• Report RIOTX collector errors in pipeline status: Failed Snowflake collectors now report their error messages through Kubernetes termination logs.
• Clean up legacy RIOTX state when resetting or removing a source: Cleanup now recognizes the legacy riotx segment in older stream names when selecting dead-letter queue entries, counters, statistics, and deduplication keys.
• Deploy pipelines with multiple source types: Fixed malformed YAML document separators in generated Kubernetes manifests that could prevent pipelines using different collector types from deploying.
• Move failed components out of pending: A pipeline whose component never becomes available now moves to error when the deployment availability timeout elapses, without needing another change to trigger reconciliation.
• Report the leader election mode consistently: With multiple operator replicas, redis-di info and GET /api/v2/info now report the mode from the replica that runs leader election.
• Keep a pipeline in error after Kubernetes rejects its configuration: When Kubernetes rejected a deployed configuration, for example an invalid port in the advanced Flink processor settings, the pipeline could restart its components repeatedly and report an unrelated error, and deploying the corrected configuration could fail. The pipeline now stays in error with the cause, keeping the components that the failed configuration created or updated, until you deploy a corrected configuration.
• Delete the state of removed components reliably: After a deploy removed a component, such as a source, its state in the RDI database, such as Debezium offsets and schema history, could remain, so a source added back later could skip its initial snapshot. RDI now reports the pipeline as updating until this state is deleted, and as error if the deletion takes longer than 90 seconds, for example because the component's pods do not terminate. RDI keeps retrying and clears the error once the state is deleted. A failed reset now also leaves the pipeline in error until a later reset succeeds, and deleting a pipeline deletes this state even if the component's pods do not terminate.
• Report classic processor throughput correctly with synchronous processing: With processors.enable_async_processing set to false, the rdi_processor_rec_per_sec_total and rdi_processor_rec_per_sec_last metrics are now computed from the total batch time, instead of the slowest of the read, process, and acknowledge times.
• Remove the double slash from metrics ingress paths: For the Debezium collector, the Flink collector, and the Flink processor, an ingress pathPrefix that ends in / now gives a metrics path without a double slash, for example /processor/metrics instead of /processor//metrics for /processor/, and /metrics instead of //metrics for /.
• Acknowledge processed records after a Flink checkpoint: Records written to the target while a checkpoint was in progress are now acknowledged and deleted from the source stream by a later checkpoint.

Improvements

• Improve job schemas: Transformation blocks and nested output arguments now describe their supported fields, types, and expression languages, improving editor autocomplete and rejecting invalid job structures earlier. A job file that an earlier version accepted can therefore fail validation, so check your configuration with redis-di deploy --dry-run before you redeploy it.
• Delete the default pipeline: DELETE /api/v2/pipelines/default and redis-di delete now delete the default pipeline instead of returning 422.
• Limit schema history to captured tables: The Debezium collector now keeps only the schema history of the captured tables for SQL Server and MariaDB sources as well as MySQL and Oracle sources, so the history stays smaller and the collector recovers faster. PostgreSQL and MongoDB keep no schema history and are unaffected. If you add a table to the tables list of an existing MariaDB or SQL Server source, or add a database or schema to the ones it captures, reset the source, or it stops with an unknown schema error when the new table first changes. Set schema.history.internal.store.only.captured.tables.ddl to false in advanced.source to keep the previous behavior.

Security

Compared with RDI 2.0.0, the following dependency updates resolve Common Vulnerabilities and Exposures (CVEs) in the listed components: