fix(parity): drive semseg goldens with the CLI's mask_id schema (di#358)#322
Merged
Merged
Conversation
The goldens-drift check went red on develop once cli#286 bumped the
data-ingestors pin past di#358, whose MaskIdColumnValidator now REQUIRES
mask_id to be a *declared schema column* (an undeclared mask_id is dropped
at ingest -> stored table lacks it -> the training client raises
FileNotFoundError, backend#816).
Root cause was in the goldens harness, not the CLI or the ingestor: the
CLI's real semseg ingest declares the mask_id column (spec.go sets
schema={'mask_id':'VARCHAR(255)'}), but gen-validator-goldens.py only
injected a schema for tabular/time-series categories. So it drove the
validators WITHOUT the schema the CLI sends, and MaskIdColumnValidator
spuriously rejected every semseg case (incl. semseg-ok). Fix: mirror
spec.go for semantic_segmentation cases (an explicit per-case schema still
wins, so the reject-path cases keep exercising the contract).
Also flips semseg-missing-mask-id's ingestor_verdict accept->reject: it has
no mask_id column, so post-di#358 the ingestor correctly rejects it (both
sides now agree). This is exactly the reconciliation the case's own note
predicted at pin-bump time. Regenerated goldens; only that one entry
changes. 'validator goldens in sync'; internal/push parity tests green.
Part of tracebloc/backend#1106 (WS-C validator mirrors).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
@BugBot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit cb7134d. Configure here.
Contributor
Author
|
👋 Heads-up — Code review queue is at 49 / 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.) |
saadqbal
approved these changes
Jul 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the red "Validator goldens vs data-ingestors @ pin" check that appeared on develop after cli#286 bumped the pin past data-ingestors #358.
Root cause — a harness bug, not the CLI or the validator
di#358's
MaskIdColumnValidatorrequiresmask_idto be a declared schema column (an undeclared mask_id is dropped at ingest → stored table lacks it → the training client raisesFileNotFoundError, backend#816). The CLI's real semseg ingest does declare it (spec.go:schema={"mask_id":"VARCHAR(255)"}) — butgen-validator-goldens.pyonly injected a schema for tabular/time-series cases, so it drove the validators without the schema the CLI sends and spuriously rejected every semseg case (includingsemseg-ok).Fix
gen-validator-goldens.py: mirrorspec.go— inject{"mask_id":"VARCHAR(255)"}forsemantic_segmentationcases (an explicit per-case schema still wins, so reject-path cases keep exercising the contract).semseg-missing-mask-id: flipingestor_verdictaccept→reject — it has no mask_id column, so post-di#358 the ingestor correctly rejects it. This is exactly the reconciliation the case's ownnotepredicted at pin-bump time; CLI and ingestor now agree.Verification
sync-validator-goldens.sh --check→ validator goldens in sync.semseg-missing-mask-id: accept→reject, with the real reject message now populated).semseg-okwas alreadyaccept— the harness just stops falsely flagging it.go test ./internal/push/...green (incl. the cli_verdict ↔ ingestor_verdict ↔ goldens cross-check). Ran locally against the pinned data-ingestors (semseg validator identical between the pin and current DI HEAD).cc @divyasinghds — this is the di#358 (backend#816) contract you enforced in the validator; flagging in case you want to eyeball the reconciliation.
🤖 Generated with Claude Code
Note
Low Risk
Test harness and generated parity fixtures only; no production ingest or CLI preflight logic changes in this diff.
Overview
Aligns the validator-parity harness with how the CLI actually ingests semantic segmentation: after the data-ingestors pin passed di#358, goldens were out of sync because the Python golden generator did not pass the same
mask_idschema the CLI sends.scripts/gen-validator-goldens.pynow setsschema/full_schemato{"mask_id": "VARCHAR(255)"}forsemantic_segmentationcases (matchingspec.go), while an explicit per-case schema still overrides—so happy paths likesemseg-okare no longer spuriously rejected in goldens.Parity fixtures update
semseg-missing-mask-id:ingestor_verdictflips from accept to reject, with an updated note that CLI and pinned ingestor now both enforce the MaskIdColumnValidator contract.goldens.jsonreflects the real reject message for that case.Reviewed by Cursor Bugbot for commit cb7134d. Bugbot is set up for automated code reviews on this repo. Configure here.