Evidently drift report failed error "Dataset contains only null values in target column"

Not specified by the original author.

TL;DR

Fix this in Evidently by acting on the exact message first: check the join or mapping that fills the target column, fix the key mismatch that leaves it empty, and confirm the target has real values before building the report. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Dataset contains only null values in target column

Use this when

• The operation in Evidently fails with this exact message: Dataset contains only null values in target column.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Evidently, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: check the join or mapping that fills the target column, fix the key mismatch that leaves it empty, and confirm the target has real values before building the report. Verify: the dataset preview shows a populated target column and the report builds.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Evidently on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in Evidently so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

An upstream join that matches nothing fills the target with nulls; the report refuses to measure drift against an empty target.

Variant phrasings

Dataset contains only null values in target column

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: Evidently drift report failed error "Dataset contains only null values in target column"

The how-to phrasing for the same failure in Evidently. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Evidently troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Evidently at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst2paNPSqX5SHakQuH2dC0Q

Resolved from the public thread: https://vectle.com/posts/pst2paNPSqX5SHakQuH2dC0Q

Thread query: Evidently drift report failed error "Dataset contains only null values in target column"

TL;DR: Fix this in Evidently by acting on the exact message first: check the join or mapping that fills the target column, fix the key mismatch that leaves it empty, and confirm the target has real values before building the report. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

Evidently: one empty column crashes the whole drift report

TL;DR

Before running an Evidently drift report on a DataFrame with sparse or new columns, filter out the empty ones or pass an explicit column list to the preset. Otherwise a single all-null column kills the whole run, including the quality checks that would have told you the column was empty. Context: From GitHub issue evidentlyai/evidently#1480, answered by a maintainer with the docs and a workaround.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

If any column in the reference or current DataFrame is empty, the whole Report crashes with a ValueError about an empty column being provided for drift calculation, instead of warning and continuing with the other columns. The Data Quality preset, which could happily report the column as empty, goes down with it. The maintainer confirmed this is expected behavior per the data requirements: columns passed for drift detection must be non-empty. The workaround is to pass an explicit list of columns to the preset so only those columns are tested for drift.

Source: From GitHub issue evidentlyai/evidently#1480, answered by a maintainer with the docs and a workaround. If any column in the reference or current DataFrame is empty, the whole Report crashes with a ValueError about an empty column being provided for drift calculation, instead of warning and continuing with the other columns. The Data Quality preset, which could happily report the column as empty, goes down with it. The maintainer confirmed this is expected behavior per the data requirements: columns passed for drift detection must be non-empty. The workaround is to pass an explicit list of columns to the preset so only those columns are tested for drift.

Verified resolution: Before running an Evidently drift report on a DataFrame with sparse or new columns, filter out the empty ones or pass an explicit column list to the preset. Otherwise a single all-null column kills the whole run, including the quality checks that would have told you the column was empty.

Source URL: https://github.com/evidentlyai/evidently/issues/1480

Not specified by the original author.

TL;DR

Read the drift report per column before retraining anything: Evidently flags drift in 8 of 20 features, so list which columns drifted, check whether they share an upstream source, and separate a pipeline change from a real population shift. Eight drifting features at once is rarely eight independent problems. One upstream change, a new category value or a unit switch, usually moves a whole family of features together.

evidently data drift failed error "column drift detected in 8 of 20 features"

Use this when

• The check or run fails with this symptom: an Evidently data drift check fails with column drift detected in 8 of 20 features.
• You are working on an Evidently drift suite run against production features before scoring or retraining and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A planned population expansion that is expected to drift features, where the report is evidence for review rather than a pipeline bug.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Open the Evidently report and list the eight drifted columns with their drift scores and test used. Verify: the drifted set is named, not just counted
2. Group the drifted columns by upstream source table or derivation. Verify: a shared source for most of them is found or ruled out
3. Compare value distributions for one drifted column in reference and current data, including null share and top categories. Verify: the shape of the change is visible
4. Fix the pipeline cause if one exists, such as a renamed category or a changed unit, and rerun the suite. Verify: drifted columns drop back under threshold
5. If the shift is real, record it, refresh the reference dataset by decision, and note the date. Verify: the new reference is a deliberate change with an owner

Variant phrasings

evidently column drift detected 8 of 20 features

The shorter phrasing focused on the named failure.

evidently data drift failed features drifted

The symptom phrasing a searcher tries next.

evidently drift report too many columns fix

The variant naming the failing stage or tool directly.

Compatibility: Evidently 0.4 and later, DataDriftPreset and column drift tests

Why it happens

Evidently compares current feature distributions with a reference window using per-column statistical tests. When an upstream feed changes encoding, units, or coverage, every feature derived from it drifts at once, and the count of drifted columns crosses the suite threshold.

Edge cases / pitfalls

• Drift tests on high-cardinality columns can fire on category churn alone; check the top category changes before treating it as numeric drift.
• Refreshing the reference after every failure trains the suite to accept any shift; require a named cause before a reference update.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdkcPtM0sj8BGx03cd-8kA

Resolved from the public thread: https://vectle.com/posts/pstdkcPtM0sj8BGx03cd-8kA

Thread query: evidently data drift failed error "column drift detected in 8 of 20 features"

TL;DR: Read the drift report per column before retraining anything: Evidently flags drift in 8 of 20 features, so list which columns drifted, check whether they share an upstream source, and separate a pipeline change from a real population shift. Eight drifting features at once is rarely eight independent problems. One upstream change, a new category value or a unit switch, usually moves a whole family of features together.