Skip to the content
  1. Work
  2. One bad row should not stop the import.

Rapport · Engineering case study

Reject the bad row. Keep the useful work.

A malformed record should not halt an entire import or cross a customer boundary. I built ingestion around isolated writes, explicit rejection reasons, and tenant-aware identity.

Explore the decisions
  • PythonImport pipeline
  • PostgreSQLRow-level savepoints

The decisions

Three decisions, the reasoning behind each, and what changed as a result.

PostgreSQL logo Fault-isolated ingestionImport example
Contain the failure

One bad row. Seven useful records survive.

Eight-row example
01Valid rowCommitted
02Valid rowCommitted
03Valid rowCommitted
04Bad priceRejected
05Valid rowCommitted
06Valid rowCommitted
07Valid rowCommitted
08Valid rowCommitted
7 committed · 1 rejected

The bad row keeps an explicit rejection reason. It does not need to erase unrelated progress.

Compare the boundaries to see the cost of coupling every row to one failure.

How it works

A quick guide to the interactive flow on this page.

Dynamic contentClick each step to see a different part of the story.

The outcome

33 passing integration tests.

The pipeline isolates bad rows, skips duplicates, and keeps tenant data separate. The recorded integration suite checks this behavior across 33 passing tests.