## TL;DR
Do not just rerun the suite: query the table for the null rows the expectation flagged, decide whether the nulls are a source bug or a rule that is too strict for a legitimately optional column, fix at that layer, and rerun only the failed expectation. Most expect_column_values_to_not_be_null failures are real nulls arriving from an upstream change, not a Great Expectations bug.

```text
great expectations error: expect_column_values_to_not_be_null validation failed
```

## Use this when
- The check or run fails with this symptom: expect_column_values_to_not_be_null returns success false with unexpected null rows.
- You are working on a Great Expectations suite guarding a production table 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 column that is documented as nullable by design, where the rule itself should be removed rather than the data fixed.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Run the single expectation against the latest batch and open the result detail to get the unexpected count and a sample of row keys, instead of reading only the suite summary. Verify: the output names the column, the null count, and sample keys
2. Query the source table directly for nulls in that column, grouped by load date or source file, to find when the nulls started. Verify: the nulls cluster on a date, file, or source system rather than spreading evenly
3. Trace one null row end to end through the upstream job and check for a renamed field, a failed join, or a new record type that never populates the column. Verify: one concrete upstream cause is identified for the sample row
4. Fix at the correct layer: repair the upstream mapping or join, backfill the affected rows, or, only if the column is genuinely optional, change the expectation to mostly with a documented threshold. Verify: the chosen fix is applied and the reasoning is recorded on the suite
5. Rerun the checkpoint on the repaired batch, then on the next scheduled batch. Verify: both runs return success true for this expectation with zero unexpected rows

## Variant phrasings
### great expectations expect_column_values_to_not_be_null unexpected_count
The result-detail phrasing, focused on reading unexpected_count and the partial unexpected list.
### expect_column_values_to_not_be_null success false
The validation-result phrasing users paste from the JSON result.
### great expectations not null expectation failing on production data
The production-data phrasing, where the fix is upstream rather than in the suite.

Compatibility: Great Expectations 0.18 and 1.x with Pandas, Spark, or SQL datasources

## Why it happens
The expectation counts any null in the column as a failure, including nulls produced by outer joins, schema changes that add records without the field, and source systems that start sending empty values. Because the check runs at the end of the pipeline, the error surfaces in Great Expectations even though the defect was introduced upstream.

## Edge cases / pitfalls
- A mostly threshold hides a growing null rate. Pair it with an alert on the null percentage itself.
- Sampling can miss nulls concentrated in one partition. Validate the failing partition in full before closing.

## Provenance

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