Redis Data Integration release notes 2.0.0 (September 2026)

Multiple sources in one pipeline, Flink as the default processor, and simpler source mTLS configuration. Database-scoped secrets, per-source reset and cleanup, expanded API diagnostics, and security updates.

What's New in 2.0.0

Breaking Changes

• The Flink processor is the default processor: A pipeline whose processors section does not set type now deploys the Flink processor instead of the classic one. Set processors.type to classic to keep deploying the classic processor.
• API v1 pipeline actions apply immediately instead of queuing:
  • POST /pipelines, PATCH /pipelines, /pipelines/undeploy, /pipelines/sources/*, /pipelines/targets/*, /pipelines/processors/*, /pipelines/secret-providers/*, /pipelines/start, /pipelines/stop, /pipelines/reset now update the Pipeline resource directly instead of posting to an internal task queue. Kubernetes errors are reported with their original status codes, rather than a generic 500.
  • A request now applies its changes immediately rather than waiting behind earlier in-flight requests, so the most recent request wins if several are issued in quick succession without waiting for each to complete. Polling GET /actions/{action_id} for an action id that a later request has superseded now returns an unknown action error instead of that action's own status.
  • POST /pipelines and PATCH /pipelines now also validate target connectivity similarly to their API v2 counterparts, and surface collector API failures as a 422, 502, 503, or 504 error response. A request that previously succeeded despite an unreachable target now fails with a validation error.
• API v1 trace endpoint returns Not Implemented: POST /trace/start now immediately returns 501 Not Implemented instead of accepting the request and queuing a trace that would never run.
• API v2 pipeline DELETE no longer empties the pipeline: DELETE /api/v2/pipelines/{name} no longer replaces the pipeline with an empty, inactive one. It now returns 404 when the named pipeline doesn't exist, and 422 for the default pipeline, since deleting it isn't supported. Use redis-di deploy --empty, or PUT /api/v2/pipelines/{name} with an empty configuration, to clear a pipeline instead.
• API v2 pipeline creation no longer validates against the Collector API: POST /pipelines no longer accepts the validate_tables and validate_cdc query parameters, and never validates a new pipeline's tables or CDC setup against the Collector API. That validation could never succeed: the Collector API is rendered by the pipeline being created, so it cannot exist yet for the request creating it. PUT /pipelines/{name} keeps both parameters, but doesn't use them when creating a new pipeline.
• API v2 pipeline responses omit optional fields that have no value: The pipeline, pipeline status, create, update, patch, start, stop, and reset responses no longer contain optional fields with null values; such fields are left out instead. This affects status_changed_at and an error's remediation. The OpenAPI schema is unchanged, since neither field was ever required, so clients generated from it are unaffected; a client that reads either key directly has to treat it as absent rather than null.
• topic.prefix is no longer accepted in advanced.source: The topic.prefix property is now rejected in a source's advanced.source section, since RDI derives the topic prefix from the source name. Remove the property from your configuration and set each job's server_name to the derived prefix: the source name, rdi for the source of an upgraded single-source pipeline handled by the Debezium collector, and the Spanner instance ID for the source of such an upgraded pipeline handled by the Flink collector.
• API v2 metric collections data stream names contain the qualified table name: The data_streams.streams keys of a metric collection are now the source-qualified table name (mysql.inventory.addresses), matching what the dead-letter queue endpoints return, instead of the Redis stream name ({rdi}:inventory.addresses). A client that uses the previous form has to be updated. API v1 statistics are unchanged.
• Cassandra is no longer a source database type: cassandra has been removed from the source database types that redis-di scaffold, the configuration template endpoint, and rdi-admin install offer, and a source whose connection type is cassandra no longer passes validation. RDI never actually supported Cassandra as source, since the Debezium Cassandra connector has to run on each Cassandra node.

New Features

• Multiple sources in one pipeline: A pipeline can ingest data from several source databases, of the same or different types, into one Redis target. Each source has its own name, connection settings, credentials, and collector. Use API v2 or the redis-di CLI to manage multi-source pipelines; API v1 supports only single-source pipelines. To reset one source while preserving the other sources' internal data, use the optional source query parameter on POST /pipelines/{name}/reset or the redis-di reset --source flag. Source reset temporarily stops and restarts the whole pipeline and does not support external sources. See Multiple sources in one pipeline.
• Transformation jobs can select several tables (Flink processor): A job's server_name, db, schema, and table source selectors now accept a list of values in addition to a single one, and an entry prefixed with regex: is matched as an anchored regular expression, so one job can handle many tables. An entry without the prefix is matched literally, so existing jobs are unaffected, including table names containing regular expression characters. Two jobs whose selectors select the same table are rejected. Only the Flink processor supports this syntax, so a job using it is rejected for the classic processor.
• Database-scoped pipeline secret keys: Pipeline secrets in API v2 and the redis-di CLI now use database-independent keys (USERNAME, PASSWORD, CACERT, CERT, KEY, KEY_PASSWORD) together with a db parameter (--db in the CLI) that specifies the database the secret belongs to: a source name, or target. The previous scope-prefixed keys (SOURCE_DB_*, TARGET_DB_*) are still accepted for single-source and target secrets, used without the db parameter.
• Richer validation errors from API v1 pipeline configuration endpoints: A 422 response from /pipelines/undeploy, /pipelines/sources/*, /pipelines/targets/*, /pipelines/processors/*, and /pipelines/secret-providers/* may now include an errors array with structured per-field detail, in addition to the existing detail message, matching the shape already returned by POST /pipelines and PATCH /pipelines. Existing clients that only read detail are unaffected.
• Pipeline components report the source they are associated with: Each collector component in an API v2 pipeline or pipeline status response now has a source field specifying the pipeline source it is associated with. It is empty for components that are not per-source, such as the processor and the Collector API.
• A follower installation keeps its pipelines instead of deleting them on leadership loss: In a high-availability RDI deployment with leader election enabled, the installation that is not currently active now keeps its Pipeline resources and reports them with a new standby status, instead of deleting them and recreating them on leadership acquisition. Mutating a pipeline (create, update, patch, delete, start, stop, reset, or start/stop a source) on a standby installation now returns 503 Service Unavailable.
• Scaffolded configurations use a descriptive source name: redis-di scaffold and the configuration template endpoint now name the generated source after the database type (for example mysql). A custom name can be passed with the new --source-name flag (source_name query parameter).
• TypeScript SDK published to npmjs: The RDI API TypeScript SDK is now publicly available on npmjs as @rdi-ui/sdk under the MIT license, so it no longer requires access to the internal GitHub Packages registry: npm add @rdi-ui/sdk.
• More collector diagnostics in API v2 metric collections: The GET /pipelines/{name}/metric-collections endpoint now reports the full set of numeric Debezium collector metrics per source: event counts by operation, filtered and erroneous events, queue capacity and byte usage, the last processed transaction id, MySQL and MariaDB binlog health counters and GTID set, MongoDB primary elections, and Oracle LogMiner SCN, lag, performance, and error metrics.
• Pipeline components report their externally-reachable endpoints: Each component in an API v2 pipeline or pipeline status response now has an external_endpoints field listing the URLs at which that component is reachable from outside the cluster.
• Source mTLS without Debezium keystore settings: A MySQL, MariaDB, or MongoDB source no longer requires setting database.ssl.keystore/mongodb.ssl.keystore and the matching password in advanced.source for mTLS to work correctly.
• Removing a source from a pipeline deletes its internal RDI data: Removing a source with PUT or PATCH /pipelines/{name} now deletes its internal RDI data, including its change streams, offsets, schema history, dead letter queue entries, statistics, deduplication state, and record counters. That data used to be kept indefinitely, and only resetting the pipeline removed it. Records already written to the target Redis database are not deleted.
• redis-di deploy --empty clears a pipeline's configuration: The new --empty flag, mutually exclusive with --dir, deploys an empty configuration instead of loading one from a directory. An empty pipeline is left stopped unless --start is passed explicitly. See Clear a pipeline.

Bug Fixes

• Collector API startup on OpenShift: Fixed a regression introduced in RDI 1.19.1 that caused pod creation to be rejected by standard OpenShift security policies when global.openShift is enabled, while preserving source certificate permissions.
• RDI database client certificates isolated from source certificates: The Debezium collector now presents its RDI database client certificate from a dedicated keystore instead of the shared default keystore, so the source database and RDI database client identities can no longer interfere with each other under mTLS.
• Nested processor properties displayed correctly in redis-di describe: Nested objects and arrays in a processor's advanced properties are now shown as JSON instead of a raw internal format, so the redis-di describe output is valid and easy to read.
• Bulk inserts after a snapshot no longer restart the Flink processor: Fixed an issue where a bulk insert arriving just after a snapshot could lead to a Flink job restart with Have records for a split that was not registered during the transition to CDC.
• Streams continue processing after a Flink processor restart: A narrow timing window around a checkpoint could leave a stream permanently unassigned to any reader after a restart (for example following a TaskManager failure), silently halting ingestion for that stream until the pipeline was redeployed. The processor now confirms with every reader before treating a stream as no longer needed.
• Unreachable source database reported as a validation error: When RDI cannot list the source tables during pipeline validation, for example because the source database refuses the connection, the failure is now reported as a 422 validation error in the errors array, instead of a 422, 502, or 504 response carrying only a detail message. An unavailable collector API is still reported as a 503 response so the request can be retried.
• Redis configuration template requests return 501 Not Implemented: GET /pipelines/config/templates/ingest/redis now returns the documented 501 Not Implemented, instead of a 200 response with an incorrect configuration. Redis cannot be used as a pipeline source.
• A database flavor that does not match the database type is rejected: GET /pipelines/config/templates/ingest/{db_type} now returns a 422 response when db_flavor names a MongoDB flavor and db_type is not mongodb, instead of a 200 response with an incorrect configuration.
• Clearing a whole configuration section with PATCH is rejected: PATCH /pipelines/{name} now returns a 422 validation error when processors, sources, or targets is set to null. Remove a section's entries individually, as in {"sources": {"mysql": null}}, or replace the whole configuration with PUT.
• A missing pipeline's 404 error message contains its name: A 404 response for a pipeline that doesn't exist is now Pipeline '<name>' not found, instead of Pipeline not found, consistent with the other error messages.

Improvements

• API response body logging: The RDI API now logs response bodies alongside request payloads. Bodies are logged at DEBUG level, while request and response metadata stays at INFO, and large bodies are truncated to keep logs manageable.
• Documented scaffolded configurations: The configuration that redis-di scaffold, the configuration template endpoint, and rdi-admin install generate now documents every property it offers, with a description above each one, links to the pipeline configuration documentation, and the default value where one exists. It also covers Snowflake and it no longer suggests properties that the source database does not support. The target port now defaults to 6379 rather than a placeholder, so the generated configuration passes schema validation before any property is filled in. The per-database example configurations that rdi-admin install wrote alongside it (config.yaml.mysql.example and its siblings) have been removed, since the generated configuration and the documentation now cover the same ground.
• Documented transformation job template: The job template that GET /pipelines/jobs/templates/ingest returns now documents the properties of the source, transform, and output blocks, with a description above each one and links to the transformation documentation, instead of naming a handful of them in a bare skeleton. It is a valid job as returned, with only the mandatory properties left uncommented. The endpoint accepts a new optional source_name query parameter that specifies the source the job reads from, matching the parameter of the configuration template endpoint. rdi-admin install now writes the same template to jobs/job.yaml, named after the source it scaffolds, in place of the example jobs it used to copy there.
• Debezium collector processes captured records on four threads: The Debezium collector now sets record.processing.threads to 4 rather than letting Debezium size the pool by itself, which raises snapshot throughput considerably. Lower it through a source's advanced.source.record.processing.threads when fewer CPUs are available to the collector.
• Faster pipeline reset: Resetting a pipeline is faster and no longer creates a Kubernetes Job.

Security

• Hardened API log redaction: Ensured secrets, credentials, tokens, and connection strings are masked in the request and response bodies the RDI API logs, with login and pipeline secret payloads fully redacted.
• Flink processor and collector security updates: Resolved CVE-2024-57699, CVE-2025-12183, CVE-2025-27820, CVE-2025-55163, CVE-2025-66566, CVE-2025-68973, CVE-2025-69720, CVE-2026-5260, CVE-2026-8376, CVE-2026-8925, CVE-2026-11822, CVE-2026-11824, CVE-2026-15146, CVE-2026-33845, CVE-2026-35194, CVE-2026-42010, CVE-2026-42013, CVE-2026-42198, CVE-2026-42496, CVE-2026-42583, CVE-2026-44249, CVE-2026-45416, CVE-2026-45447, CVE-2026-50010, CVE-2026-50813, CVE-2026-54291, CVE-2026-54399, CVE-2026-54428, CVE-2026-54512, CVE-2026-54513, CVE-2026-58472, CVE-2026-59901, and GHSA-r7wm-3cxj-wff9.
• Monitor security updates: Resolved CVE-2024-6345 and CVE-2025-47273.
• Collector API security updates: Resolved CVE-2025-66566, CVE-2026-10050, CVE-2026-40973, CVE-2026-40983, CVE-2026-40984, CVE-2026-42198, CVE-2026-42579, CVE-2026-42583, CVE-2026-44249, CVE-2026-45416, CVE-2026-45674, CVE-2026-47691, CVE-2026-50010, CVE-2026-54291, CVE-2026-54512, CVE-2026-54513, CVE-2026-59901, and GHSA-r7wm-3cxj-wff9.
• Shared utilities security updates: Resolved CVE-2026-21441 and CVE-2026-33154.
• Operator security updates: Resolved CVE-2026-24051, CVE-2026-33186, CVE-2026-35469, CVE-2026-39821, CVE-2026-39829, CVE-2026-39830, CVE-2026-39831, CVE-2026-39832, CVE-2026-39833, CVE-2026-39834, CVE-2026-42508, CVE-2026-46595, CVE-2026-46597, CVE-2026-46680, CVE-2026-50151, CVE-2026-50163, CVE-2026-53488, and GHSA-hrxh-6v49-42gf.
• Collector initializer security update: Upgraded jq to resolve CVE-2026-32316, CVE-2026-33947, CVE-2026-33948, CVE-2026-39979, CVE-2026-40612, CVE-2026-41256, CVE-2026-41257, CVE-2026-43894, CVE-2026-43895, CVE-2026-43896, CVE-2026-44777, CVE-2026-47770, CVE-2026-49839, and CVE-2026-54679.
• Fluentd security updates: Resolved 20 unique CVEs compared with the previous image, including 1 Critical and 11 High findings: CVE-2025-46394, CVE-2025-60876, CVE-2025-6442, CVE-2026-7383, CVE-2026-9076, CVE-2026-22184, CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790, CVE-2026-34180, CVE-2026-34182, CVE-2026-42766, CVE-2026-42767, CVE-2026-42770, CVE-2026-45445, CVE-2026-45446, and CVE-2026-45447.
• Classic processor security updates: Resolved CVE-2024-6345, CVE-2025-47273, and CVE-2025-67221.
• API security updates: Resolved CVE-2024-53981, CVE-2024-6345, CVE-2025-47273, CVE-2025-62727, CVE-2026-24486, CVE-2026-32597, CVE-2026-42561, CVE-2026-48522, CVE-2026-48523, CVE-2026-48524, CVE-2026-48525, CVE-2026-48526, CVE-2026-48710, CVE-2026-53539, and CVE-2026-54283.
• Metrics aggregator security updates: Resolved CVE-2024-6345, CVE-2025-47273, CVE-2025-62727, CVE-2025-66418, CVE-2025-66471, CVE-2026-23490, CVE-2026-26007, CVE-2026-30922, CVE-2026-32597, CVE-2026-48710, and CVE-2026-54283.