## TL;DR
Pandera's failure cases tell you exactly which rows and values broke the schema: read the failure_cases frame from the SchemaErrors output, count nulls in the non-nullable columns, and trace whether the nulls come from the source or from a merge that introduced them. Setting the column nullable to silence it should only happen with a contract change everyone downstream accepts.

```text
pandera error: schema errors failure cases null values in non-nullable column failed
```

## Use this when
- The check or run fails with this symptom: the Pandera failure cases show null values in columns marked non-nullable.
- You are working on a Pandera validation where non-nullable columns contain nulls 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 dtype-only Pandera failure with no nulls involved, which follows the dtype path instead.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Catch the SchemaErrors exception and print its failure_cases to list columns, row indexes, and failure types. Verify: the failure cases are listed concretely
2. Count nulls per non-nullable column in the raw input and in the transformed frame to locate where they appear. Verify: null appearance is located to a pipeline stage
3. Inspect that stage for left joins, optional source fields, or a fill step that was removed. Verify: the introducing stage is identified
4. Fix the stage: populate the field, filter incomplete records explicitly, or change the schema's nullable setting only as a documented contract change. Verify: the frame and schema agree by decision
5. Rerun validation and confirm zero failure cases, then validate a deliberately null-containing frame to prove the check still bites. Verify: clean data passes and bad data still fails

## Variant phrasings
### pandera schema errors failure cases null values
The verbatim failure-cases phrasing.
### pandera non-nullable column contains nulls fix
The fixing phrasing for locating the introducing stage.
### pandera nullable false validation failing join
The join phrasing for merge-introduced nulls.

Compatibility: Pandera schemas with nullable settings and failure-case reporting

## Why it happens
Pandera collects every schema violation into failure cases, and nulls in non-nullable columns usually trace to one stage that can emit incomplete rows. The failure list is precise; the work is mapping row indexes back to the stage that produced them.

## Edge cases / pitfalls
- Persist failure_cases with the run. They are the fastest debugging artefact Pandera gives you.
- Validate at stage boundaries in long pipelines so the introducing stage is obvious from the first failure.

## Provenance

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