{
  "schema_version": 2,
  "id": "integrate/redis-data-integration/release-notes/rdi-2-0-0",
  "title": "Redis Data Integration release notes 2.0.0 (September 2026)",
  "url": "https://redis.io/docs/latest/integrate/redis-data-integration/release-notes/rdi-2-0-0/",
  "summary": "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.",
  "tags": [
    "docs",
    "operate",
    "rs"
  ],
  "last_updated": "2026-09-18T16:47:10+01:00",
  "page_type": "content",
  "content_hash": "411dd6cfd26631eb052ad97b775262d2dc75c3b2e0b353a3e3379ce71efbc1ac",
  "sections": [
    {
      "id": "whats-new-in-200",
      "title": "What's New in 2.0.0",
      "role": "overview",
      "text": ""
    },
    {
      "id": "breaking-changes",
      "title": "Breaking Changes",
      "role": "content",
      "text": "- **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.\n- **API v1 pipeline actions apply immediately instead of queuing**:\n  - `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.\n  - 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.\n  - `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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **`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.\n- **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.\n- **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."
    },
    {
      "id": "new-features",
      "title": "New Features",
      "role": "content",
      "text": "- **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](https://redis.io/docs/latest/integrate/redis-data-integration/data-pipelines/multiple-sources).\n- **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.\n- **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.\n- **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.\n- **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.\n- **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`.\n- **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).\n- **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`.\n- **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.\n- **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.\n- **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.\n- **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.\n- **`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](https://redis.io/docs/latest/integrate/redis-data-integration/data-pipelines/deploy#clear-a-pipeline)."
    },
    {
      "id": "bug-fixes",
      "title": "Bug Fixes",
      "role": "content",
      "text": "- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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.\n- **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`.\n- **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."
    },
    {
      "id": "improvements",
      "title": "Improvements",
      "role": "content",
      "text": "- **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.\n- **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.\n- **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.\n- **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.\n- **Faster pipeline reset**: Resetting a pipeline is faster and no longer creates a Kubernetes Job."
    },
    {
      "id": "security",
      "title": "Security",
      "role": "security",
      "text": "- **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.\n- **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`.\n- **Monitor security updates**: Resolved `CVE-2024-6345` and `CVE-2025-47273`.\n- **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`.\n- **Shared utilities security updates**: Resolved `CVE-2026-21441` and `CVE-2026-33154`.\n- **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`.\n- **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`.\n- **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`.\n- **Classic processor security updates**: Resolved `CVE-2024-6345`, `CVE-2025-47273`, and `CVE-2025-67221`.\n- **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`.\n- **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`."
    }
  ],
  "examples": []
}