Skip to content

chore(data ingest): re-land #147 preflight parity onto ux (stacked-base miss) - #151

Closed
saadqbal wants to merge 2 commits into
ux/cli-surface-and-namespace-discoveryfrom
reland/147-preflight-parity
Closed

chore(data ingest): re-land #147 preflight parity onto ux (stacked-base miss)#151
saadqbal wants to merge 2 commits into
ux/cli-surface-and-namespace-discoveryfrom
reland/147-preflight-parity

Conversation

@saadqbal

@saadqbalsaadqbal commented Jul 7, 2026

Copy link
Copy Markdown
Collaborator

Why

PR #147 was stacked on `feat/ingest-guard-and-extension` (PR #145's head), so its `baseRefName` was that feature branch, not `ux/cli-surface-and-namespace-discovery`. When #145 merged first and #147 merged second, GitHub merged #147 into `feat/ingest-guard-and-extension` — the preflight-parity payload never reached `ux`.

This carries just the #147 delta onto `ux` (cherry-pick `-m1` of the #147 merge; 145's changes are already on `ux` as `090be58`, so a whole-branch merge would only conflict 145 against its own squash).

What

  • `internal/push/preflight.go` (+673) + `preflight_test.go`, `parity_golden_test.go`, parity goldens/testdata
  • `internal/cli/data.go`, `spec.go` wiring
  • `scripts/gen-validator-goldens.py`, `sync-validator-goldens.sh`, `install.ps1`

63 files, +1748 / -32.

Verification

  • Clean cherry-pick onto `ux` HEAD, no conflicts
  • `go build ./...` OK
  • `go test ./internal/push/... ./internal/cli/...` green

Rolls up under the #145 / #147 tickets — no new kanban item.


Note

Medium Risk
Touches the core data ingest pre-upload path and spec emission for target_size; wrong parity or ordering would false-reject good datasets or still allow bad uploads, but behavior is heavily pinned by parity goldens and unit tests.

Overview
Re-lands the #147 preflight-parity work onto ux so data ingest can catch the same data problems locally that the in-cluster ingestor would reject after a full upload.

Local preflight (internal/push/preflight.go) adds PreflightDataset and named checks that mirror data-ingestors rules: UTF-8/NUL CSV encoding, tabular BOM (schema probe vs pandas), duplicate headers, empty/header-only CSVs, label column matching, schema columns, label diversity (including tabular VARCHAR vs numeric collapse), full-image decode for corrupt/zero-byte/resolution mismatches, labels↔images cross-check, and object-detection annotation pairing. runLocalPreflight in data.go runs this after ingest.v1 schema validation and before cluster discovery; flag problems exit 2, data problems exit 3. Tabular paths also reject BOM’d CSVs early so InferSchema isn’t corrupted.

target_size emit fix in spec.go: emitted order is [width, height] (PIL order), undoing an [H,W] swap that broke non-square image datasets in-cluster.

Parity harness: parity_golden_test.go, fixture cases, committed goldens.json, and scripts/gen-validator-goldens.py / sync-validator-goldens.sh pin Go preflight vs real Python validators (with documented deliberate divergences where the CLI previews read/transfer-time failures).

Reviewed by Cursor Bugbot for commit 1fdd8b5. Bugbot is set up for automated code reviews on this repo. Configure here.

… checked contract (#147)
backend#828 P3; closes cli#69, cli#71, cli#72, cli#73.
Every local check now previews a NAMED data-ingestors validator with
matching semantics, so 'preflight passed' means the in-cluster
validation passes too — failures land BEFORE the upload, not after.
New previews (internal/push/preflight.go, each cites its source rule):
- label column exists (LabelColumnValidator: exact, then
case-insensitive+trimmed — never stricter than the cluster) (#69)
- BOM: tabular rejected pre-upload (the in-cluster stdlib schema probe
falsely rejects BOM'd CSVs — data-ingestors#338); image/text BOM
accepted+stripped, matching the pandas paths (#71)
- every image decoded (header-only, cheap): zero-byte, corrupt,
resolution vs target — plus the labels↔images cross-check with the
ingestor's _has_extension naming semantics (dotted stems!) (#72)
- duplicate headers (stripped, case-SENSITIVE like the probe), zero
data rows, --schema columns ⊆ header, CSV encoding gate
(check_csv_encoding preview: UTF-8 + no NUL) (#73 + gaps found)
- label diversity (LabelDiversityValidator: >=2 classes; NA-sentinel
drop + numeric collapse for schema-typed tabular labels; empty
string IS a class for image/text) — discovered BY the harness's
first run, was in no ticket
- object_detection images↔annotations stem pairing
(FilePairingValidator preview)
FIXES A PRE-EXISTING SHIP-BLOCKER found by the adversarial pass:
spec.go swapped target_size to [H,W] on emit (mistaken review note) —
but the schema + ImageResolutionValidator compare PIL's (W,H) verbatim,
so EVERY non-square dataset failed in-cluster post-upload. Emission is
now [W,H]; the parity pair imgc-nonsquare / imgc-nonsquare-swapped pins
the orientation end-to-end against the real validator.
THE PARITY HARNESS (the durable part):
- internal/push/testdata/parity: 23 fixture cases + goldens.json
GENERATED from the real Python validators
(scripts/gen-validator-goldens.py; scripts/sync-validator-goldens.sh
--check for drift, verdict-level)
- parity_golden_test.go asserts the PRODUCTION dispatch
(push.PreflightDataset — shared by runDataIngest and the test, so
the two cannot drift) reaches the manifest's verdict per case, and
that committed goldens match the manifest — an ingestor rule change
fails the test until consciously reconciled
- deliberate divergences (read-/transfer-time failures the ingestor's
preflight can't see but the CLI previews) are explicit manifest
notes, never silent
Verified: 23/23 parity green; full go test green; live dry-runs on a
real cluster (missing file, bad label column, single-class, latin-1,
non-square 320x200 accept). Adversarial review (2 lenses, high
effort): all findings folded incl. the [W,H] bug, value-semantics
divergences in diversity/cross-check, the encoding gate, de-masked
fixtures, the shared dispatch, and a vacuous kubeconfig test revived
with decodable fixtures.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@LukasWodka

Copy link
Copy Markdown
Contributor

👋 Heads-up — Code review queue is at 35 / 30

Above the WIP limit. The team convention is to review existing PRs before opening new work.

Open PRs currently in Code review (oldest first):

Pull from review before opening new work. (This is a nudge from the kanban WIP check, not a block.)

@cursorcursorBot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit dc44ae1. Configure here.

Comment threadinternal/push/preflight.go
CheckLabelDiversity collapsed numeric-looking labels ("1"/"1.0") for
every tabular_classification dataset. The in-cluster LabelDiversityValidator
pins dtype=str for string-family schema types (VARCHAR/CHAR/TEXT/STRING),
so those labels stay distinct — only numeric types get pandas numeric
inference (data-ingestors #252). A user-declared VARCHAR label with
numeric-looking classes was wrongly rejected at preflight.
Derive the drop-NA and collapse-numeric flags from the label's declared
schema type at the dispatch site; keep image/text (untyped) unchanged.
Adds leaf + dispatch tests. This aligns the Go side with the golden
generator, which already types columns as VARCHAR.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@saadqbal

Copy link
Copy Markdown
CollaboratorAuthor

Superseded by the reland → develop path (#149 + #150). This targeted ux/cli-surface-and-namespace-discovery, whose surface work already landed on develop as #142/#144, so ux → develop conflicts — a dead end. The Bugbot fix from here is carried onto the reland path in #152.

@saadqbalsaadqbal closed this Jul 7, 2026
@saadqbal
saadqbal deleted the reland/147-preflight-parity branch July 7, 2026 09:55
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@saadqbal@LukasWodka