Skip to content

cli: os i18n extract --check --json exits 0 having compared nothing — the second false green on this command #16600

Description

@claude

Measured by the os-dev seat implementing #16480 (the --check --dry-run false green), on the same fixture and with the same method. Reported rather than swept in: see "Why this is not folded into that PR" below.

What was measured

os i18n extract CONFIG --locales=zh-CN --no-metadata-forms --out=DIR --check --json exits 0 having compared nothing, on a tree whose bundles have provably drifted.

Driven on one fixture, same --out, with its own positive control:

invocation exit what it reported
... --out=DIR --check 1 missing: DIR/zh-CN.objects.generated.ts then Translation bundles have drifted from the schema
... --out=DIR --check --json 0 the ordinary extract payload (totalExpected, counts, bundles, ...) — no drift field, no comparison, no failure

The two runs differ only by --json, and the first one proves the drift is really there.

Mechanism, read off the code

packages/cli/src/commands/i18n/extract.ts: the if (flags.json) { await emitJson(...); return; } block sits ahead of both the --check needs --out guard and the --check comparison block. So --json returns before anything is compared, exactly as the --dry-run branch did in #16480 — a different branch, the same shape, and the same direction.

Why this is its own card

This is the identical class to #16480 and its dangerous direction: a check that cannot fail is indistinguishable from a check that finds nothing. --json is if anything the more likely CI spelling of the two, because a pipeline that wants to parse the result reaches for it.

Why this is not folded into the #16480 PR

That card's dispatch scoped the work to the --dry-run branch, and this one is not a mechanical repair of the same kind. Removing the false green here requires deciding the payload contract: what a --json --check run reports when it finds drift (a drift / missing / stale member? the existing error envelope? both?) and what its exit code is. That is a new public output shape for a published command, not a control-flow correction, so it is stated as a question rather than answered here.

⛔ Not graded here. Grading and routing are triage's.

Re-check

# in a fixture whose committed bundle has drifted:
os i18n extract CONFIG --locales=L --no-metadata-forms --out=DIR --check           # expect exit 1
os i18n extract CONFIG --locales=L --no-metadata-forms --out=DIR --check --json    # observed exit 0, nothing compared

Dedupe

One targeted semantic search over this repo, open and closed, with a live positive control: the query returned #16480, #14894, #16242, #14895 and #16121 — the nearest known cards of this command family — with incomplete_results: false, so the absence of a match for this defect is a reading and not a silent zero. Nearest neighbours read and distinguished: #16480 (--check --dry-run, the sibling branch, being fixed now — it does not touch the --json path), #14894 (closed, --no-metadata-forms ignored under --no-objects-only), #16242 (--source-hashes drops non-objects provenance), #14015 (closed, a docs card about os lint --json's conversions key, a different command). No open card covers this.

Refs: #16480 (the --dry-run twin).

Filed from the os-dev seat using Claude Code; this sentence is the attribution, since trailing footer blocks are stripped on issue creation.


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions