> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open-metadata.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Breaking Changes - Data Quality | Official Documentation

> Incidents as Tasks, inlined incident status, incident auto-close, multi-status filters, batch DQ reporting and the removed Data Insights data quality module in OpenMetadata 2.0.

# Data Quality & Observability

Test cases, incidents and the reporting surface all change shape in 2.0.

## Incidents move onto the Task entity

<Warning>
  **Breaking.** Affects incident automation and feed-based incident integrations.
</Warning>

|           | 1.13                              | 2.0                                                       |
| --------- | --------------------------------- | --------------------------------------------------------- |
| Storage   | `thread_entity` (`type=Task`)     | `task_entity`                                             |
| Task type | thread task type                  | `TestCaseResolution` / `IncidentResolution`               |
| Category  | —                                 | `Incident`                                                |
| Payload   | untyped `taskDetails`             | `testCaseResolutionPayload` / `incidentResolutionPayload` |
| Resolve   | `PUT /v1/feed/tasks/{id}/resolve` | `POST /v1/tasks/{id}/resolve`                             |

The test case resolution status time series is unchanged — it still drives incident state. What
changed is the **task** that hangs off it.

<Note>
  `POST /v1/feed` still accepts test-case-failure-resolution task types, so existing integrations keep
  working. New work should target `/v1/tasks`.
</Note>

The migration also corrects the recognizer feedback task type and re-points mention alerts at the task
resource so incident-task comment mentions and assignee alerts keep firing.

## `incidentStatus` is inlined on TestCase

<Info>
  **Additive.** Removes a lookup per test case.
</Info>

```json theme={null}
"incidentStatus": {
  "description": "Latest incident resolution status for this test case. Inlined so clients can render
   the current incident status without an additional lookup per test case.",
  "$ref": "./testCaseResolutionStatus.json"
}
```

<Tip>
  Drop the per-test-case incident-status round trip in list views. The field is populated on the test
  case itself.
</Tip>

## Incident auto-close on test pass

<Info>
  **Additive and opt-in per test case.**
</Info>

```json theme={null}
"autoCloseIncident": {
  "description": "Automatically resolve an open incident when a subsequent test result succeeds.",
  "type": "boolean",
  "default": false
}
```

When enabled and a subsequent result succeeds, OpenMetadata finds the open `TestCaseResolution` task
for the test case, rehydrates it so workflow transitions are available, and resolves it as `Completed`
with reason **`AutoResolved`**, acting as the governance bot.

<Warning>
  The default is `false`, so behaviour is unchanged unless you opt in. In 1.13 an incident stayed open
  indefinitely after the underlying failure was fixed. 2.0 makes auto-close available but does not
  enable it retroactively.
</Warning>

## Multi-status test case filtering

`GET /v1/dataQuality/testCases` binds `testCaseStatus` as a repeated parameter:

```http theme={null}
GET /api/v1/dataQuality/testCases?testCaseStatus=Failed&testCaseStatus=Aborted
```

Values are validated against the status enum and an unknown value returns `400` listing the allowed
values. Previously an invalid status was tolerated.

In the UI, the Test Cases, Test Suites, Test Definitions, Incidents and Data Quality Dashboard pages
all move to the shared filter-chip pattern, with multi-select on **Platform**, **Status** and **Tags**,
searchable **Table**, **Tags**, **Service** and **Data Product** filters, and a date control for
**Last Run**.

## Batch data quality reporting

<Info>
  **Additive.** Replaces N sequential report calls.
</Info>

```http theme={null}
POST /v1/dataQuality/testSuites/dataQualityReport/batch
```

```json theme={null}
{
  "requests": [
    { "key": "byStatus",    "index": "testCase", "aggregationQuery": "…", "q": "…", "domain": "…" },
    { "key": "byDimension", "index": "testCase", "aggregationQuery": "…" }
  ]
}
```

Each request carries a client-supplied `key` used to correlate it with its result in the response.

## Data Insights no longer computes data quality

<Warning>
  **Breaking.** Affects `DataInsightsApplication` configuration and Data Insights dashboards built on
  the data quality module.
</Warning>

```diff theme={null}
- "dataQualityConfig": { "enabled": true },
  "moduleConfiguration": {
-   "dataQuality": { "$ref": "#/definitions/dataQualityConfig" },
-   "required": ["dataAssets", "appAnalytics", "dataQuality", "costAnalysis"]
+   "required": ["dataAssets", "appAnalytics", "costAnalysis"]
  }
```

`moduleConfiguration` is `additionalProperties: false`, so **any persisted configuration still
carrying the `dataQuality` key makes `DataInsightsApplication` fail to deserialise on startup**. The
migration strips it from `installed_apps`, `apps_marketplace` and every application version row.

What replaces it: test case results and resolution statuses are read **straight from their live search
indexes**, which search indexing now owns. This also drops the previous **30-day cap** on incident
data in Data Insights — incident history is no longer truncated.

<Warning>
  Do not replay a 1.13 Data Insights application configuration into 2.0. Strip
  `moduleConfiguration.dataQuality` before pushing stored configuration through the API or your
  infrastructure-as-code.
</Warning>

Related Data Insights fixes in 2.0:

* A chart metric with no function or formula returns `400`, not `500`.
* Chart formulas are validated by the Data Insights formula evaluator, not the policy validator.
* `entityStatus` is snapshotted so charts can filter by lifecycle status.
* `classificationTags` and `glossaryTags` are projected into the snapshot.
* Nested subfields are no longer advertised as chart fields.
* Enricher step failures are isolated, with per-step entity statistics.

## Custom SQL test definitions — documentation correction

<Note>
  **Not a behaviour change — a corrected description.**
</Note>

The `sqlExpression` description was rewritten in 2.0:

<Tabs>
  <Tab title="1.13 description (incorrect)">
    Supports substitution variables: `{table}` and `{column}` for runtime entity references, and
    `{{paramName}}` for user-defined parameters.
  </Tab>

  <Tab title="2.0 description (accurate)">
    The template is rendered with Jinja2, so every substitution variable must use double curly braces:
    `{{ table_name }}` for the runtime table reference, `{{ column_name }}` for the runtime column
    reference (column-level test definitions only), and `{{ paramName }}` for user-defined parameters.
    Single-brace placeholders are not substituted and will produce invalid SQL.
  </Tab>
</Tabs>

The renderer is identical in both releases — single-brace placeholders never worked. If you followed
the 1.13 documentation and wrote `{table}`, your test was already producing invalid SQL.

<Tip>
  Audit custom SQL test definitions for single-brace placeholders and convert them to
  `{{ table_name }}` and `{{ column_name }}`.
</Tip>

## Profiler & sampling

<Warning>
  **Cardinality distribution is no longer part of the Profiler agent defaults.** If you rely on distinct
  value distributions — in dashboards, in downstream analytics, or to feed an AI agent — add the metric
  back explicitly on the profiler agent.
</Warning>

<Note>
  **The profiler workflow samples dynamically by default** rather than reading 100% of rows.
  `sampleConfigType` defaults to `DYNAMIC`, which sizes the sample from the table's row count. Set a
  static sample explicitly if you need full-table profiling. The sampling configuration *schemas* are
  unchanged between 1.13 and 2.0.
</Note>

2.0 adds:

* Progress tracking for the profiler and auto-classification workflows.
* The sample configuration is used for data quality sample data ingestion.
* `tableCustomSQLQuery` honours `computePassedFailedRowCount`.
* The sampler interface collapses to a single typed configuration object — relevant if you maintain a
  custom sampler.

`columnProfile.cardinalityDistribution` moves from an inline object to a named schema definition. The
wire shape is unchanged; regenerate specification-derived models.

## Test suite & test case search

<Info>
  **Additive.** Test suites and test cases are vectorised for hybrid search, `search_metadata` can search
  them, and orphan test cases no longer break search indexing.
</Info>

## Observability UI

<Note>
  **Behavioural.** Affects forks and plugin authors.
</Note>

* `ObservabilityRouterClassBase` replaces the shared router utilities for data quality and
  observability navigation paths, making them overridable by downstream distributions.
* Test case and bundle-suite forms migrate from AntD `Form` to **react-hook-form** with reusable field
  docs. `EditTestCaseModal`, `EditTestCaseModalV1`, `TestCaseForm`, `TestCaseFormV1` and
  `BundleSuiteForm` are removed.
* Incident test-case status and severity components move to the shared core components.
* Data quality dashboard hooks and presentational components are extracted and shared.

<Tip>
  Forks that imported `EditTestCaseModal`, `TestCaseForm` or `BundleSuiteForm` directly must move to the
  new hook-and-component split. See
  [UI, Personas & Customization](/v2.0.x-SNAPSHOT/deployment/upgrade/breaking-changes/ui-and-customization).
</Tip>