fix(engine): match enum keys case-insensitively when no exact key matches - #16
Merged
llbartekll merged 1 commit intoSep 28, 2026
Merged
Conversation
…ches A bool argument renders as "true"/"false", but descriptors may spell the enum keys "True"/"False" (e.g. registry/flyingtulip/calldata-PftNft.json in the ERC-7730 registry). The exact HashMap lookup missed, so the field showed the raw value "true" instead of "Grant all". Move the enum lookup into a shared lookup_enum_label helper used by both the calldata and EIP-712 paths. It still tries an exact match first and only falls back to an ASCII case-insensitive comparison, which mirrors what @ethereum-sourcify/clear-signing does. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
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.
Problem
The
enumformatter looks up the field value with an exact string match. Aboolargument renders as"true"or"false", but a descriptor may spell the enum keys"True"and"False". The lookup then misses and the raw value is shown.Seen in the ERC-7730 registry CI on the PR that adds two Sourcify-found deployments to the Flying Tulip pFT NFT descriptor, ethereum/clear-signing-erc7730-registry#2926 (job log):
The descriptor has:
and formats
setApprovalForAll(address operator, bool approved)'sapprovedwith"format": "enum","$ref": "$.metadata.enums.rights".The ERC-7730 schema only says that enum keys are "the field values". It does not fix a spelling for booleans, and the registry has both:
ekubo/calldata-MEVCaptureRouter.jsonuses"true"/"false",flyingtulip/calldata-PftNft.jsonused"True"/"False".@ethereum-sourcify/clear-signingresolves both, because itsresolveEnumLabelfalls back to a case-insensitive key scan after an exact miss.Change
lookup_enum_labelinengine.rs. It resolves the enum byenumPath(v1) or$ref(v2), tries an exact key match first, and only then compares keys witheq_ignore_ascii_case.format_enum(calldata) and theFieldFormat::Enumarm ineip712.rsboth call it. This removes the duplicated lookup code in the two files.True/Falsekeys, an exact key still wins over a case-insensitive one,enumPathworks, and unknown enums or keys still returnNoneso the raw value is rendered as before.Integer enums are unaffected: their keys are decimal strings, which have no case.
Testing
cargo fmt --checkpasses and the new unit tests pass:I did not run the full suite or clippy locally, so please rely on CI for those.
🤖 Generated with Claude Code