Skip to content

feat(schema): add --v2, so the v2 model's schema can be printed - #347

Open
venugopalanvip wants to merge 1 commit into
LedgerHQ:mainfrom
venugopalanvip:schema-v2-flag
Open

venugopalanvip wants to merge 1 commit into
LedgerHQ:mainfrom
venugopalanvip:schema-v2-flag

Conversation

@venugopalanvip

Copy link
Copy Markdown
Contributor

The gap

schema is the only command with no way to reach the v2 models:

command v2
lint --v2, or detected from $schema
resolve --v2, or detected
calldata --v2, or detected
convert erc7730-to-eip712 detected
schema no option — always printed v1

So erc7730 lint --v2 validates against the v2 models, but the schema it enforces could not be obtained from the tool at all.

Why that schema is the one worth printing

A descriptor in the clear-signing registry is validated twice, against two independently maintained things:

  • specs/erc7730-v2.schema.json, written by hand, in the validate JSON schemas job;
  • these pydantic models, by erc7730 lint, in the validate descriptors job.

When the two disagree, a descriptor passes one check and fails the other. That is exactly #338: erc7730 generate emits metadata.info.legalName, lint accepts it, and the registry's schema rejects it. Printing the model's schema is how a comparison like that gets made in the first place.

The change

A --v2 flag, matching how lint declares its own, and switching both forms — schema input --v2 and schema resolved --v2. The v2 imports are local to the branch, as in the other commands.

$ erc7730 schema input            121,912 bytes
$ erc7730 schema input --v2       123,036 bytes
$ erc7730 schema resolved          93,441 bytes
$ erc7730 schema resolved --v2     99,506 bytes

Tests

All four combinations, plus one that checks the flag actually reaches the v2 model rather than only that a schema was printed — exit code 0 would not have caught a wiring mistake here, since both models are named InputERC7730Descriptor:

assert "excluded" in v1 and "mustMatch" not in v1
assert "mustMatch" in v2 and "excluded" not in v2

mustMatch is a v2 visibility rule and excluded a v1 field, so each name appears in exactly one of the two schemas.

One thing worth knowing

Both models carry the same title (InputERC7730Descriptor), so the two schemas are not self-identifying — only their contents differ. Anyone diffing them has to track which is which. Renaming a model's title is a wider change than this flag, so I have left it; worth a follow-up if you would rather the output named its version.

`erc7730 schema` was the only command with no way to reach the v2 models.
`lint`, `resolve`, `calldata` and `convert` all take --v2 or detect it from
$schema; `schema` printed the v1 model either way, so the schema that
`erc7730 lint --v2` actually enforces could not be obtained from the tool.

That is the schema worth having. A descriptor is validated twice by the
clear-signing registry: against `specs/erc7730-v2.schema.json`, which is
maintained by hand, and against these models, by `erc7730 lint`. When the two
disagree the descriptor passes one check and fails the other, which is what
issue LedgerHQ#338 is. Printing the model's schema is how that comparison gets made.

The flag switches both forms, so `schema resolved --v2` works too. Tests cover
all four combinations and assert the flag reaches the v2 model rather than only
that a schema was printed: `mustMatch` is a v2 visibility rule and `excluded` a
v1 field, so each name appears in exactly one of the two schemas.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

This branch has not been deployed

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant