Return typed errors from blockchain #1233
Merged
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.
Return typed blockchain protocol errors and update
pkg/blockchainerror handling to supporterrors.Is/AsIntroduce package-level typed protocol errors and refactor error handling to propagate and unwrap them throughout
pkg/blockchain. TheprotocolErrorsDictionarynow maps 4-byte selectors toerrorvalues,BlockchainErrorcarries bothprotocolErrandoriginalErr, andtryExtractProtocolErrorreturns a typed protocol error with a separate failure indicator. Tests validate selector hashing against error signatures.pkg/blockchainglobals to define typed protocol errors and changeprotocolErrorsDictionarytomap[string]errorin errors.goBlockchainErrorto storeprotocolErrandoriginalErr, modifyError()to preferoriginalErrwhen extraction fails, addUnwrap()forerrors.Is/As, and reimplementIsNoChange()usingerrors.Isin errors.gotryExtractProtocolErrorto return(protocolErr error, err error)and use sentinel errors for failure cases in errors.goTestBlockchainErrorHashesto assert keccak256-derived 4-byte selectors match dictionary keys in errors_test.go📍Where to Start
Start with the
NewBlockchainErrorconstructor and its use oftryExtractProtocolErrorin errors.go.📊 Macroscope summarized 5433d13. 1 files reviewed, 93 issues evaluated, 87 issues filtered, 1 comment posted
🗂️ Filtered Issues
pkg/blockchain/errors.go — 1 comment posted, 93 evaluated, 87 filtered
protocolErrorsDictionarymapped codes to full human-readable strings (including parameter names, e.g.,"InsufficientDeposit(uint96 amount, uint96 minimumDeposit)"). The new implementation maps codes to pre-constructederrorinstances whose messages use type-only signatures without parameter names (e.g.,"InsufficientDeposit(uint96,uint96)"). For callers that surface these messages to users or perform exact-match comparisons, this is a runtime behavior change that can cause mismatches, misclassification, or degraded diagnostics. [ Low confidence ]ErrAlreadyClaimedis"AlreadyClaimed(uint32,uint256)"instead of the prior"AlreadyClaimed(uint32 originatorNodeId, uint256 payerReportIndex)"). This is a contract/behavior change: any code that parses or displays these messages (including potential regex-based parsing hinted byErrCompileRegex) will see different strings at runtime, potentially breaking parsing logic or degrading user-facing error detail. [ Low confidence ]ErrInvalidHTTPAddressis"InvalidHttpAddress()"(lowercase 'Http'), which does not match the canonical name implied by the variableErrInvalidHTTPAddressand the dictionary key labeled asInvalidHTTPAddress. If any code compareserror.Error()to a canonical protocol error name with uppercaseHTTP, this mismatch will cause incorrect behavior (e.g., failed matching, misclassification, or broken parsing). To fix, change the message to"InvalidHTTPAddress()". [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"that previously mapped to"ERC721InvalidOwner(address owner)". Only"0x89c62b64": ErrERC721InvalidOwnerremains. If upstream contracts or logs can emit the0x7e273289selector, lookups will now fail to resolve toErrERC721InvalidOwnerand will instead fall through to error handling paths for unknown codes (e.g., returningErrCodeNotInDicelsewhere). This is a behavior regression that can lead to incorrect error decoding for valid inputs. [ Low confidence ]protocolErrorsDictionaryno longer includes the previously present key"0x7e273289"which mapped toERC721InvalidOwner(address owner). The new map retains only"0x89c62b64": ErrERC721InvalidOwner. This removal changes runtime behavior: any error code0x7e273289that was previously recognized will now be treated as unknown (e.g., consumers may returnErrCodeNotInDic). This is a contract parity break compared to the prior implementation, potentially causing misclassification or loss of detail for that error code. [ Low confidence ]protocolErrorsDictionaryno longer includes a mapping for the known ERC721 error selector"0x7e273289"which previously mapped to"ERC721InvalidOwner(address owner)". In the updated code, only"0x89c62b64": ErrERC721InvalidOwneris present. Any upstream logic that attempts to decode an on-chain revert using selector"0x7e273289"will fail to resolve to a specific error and will likely fall back to a generic handling (e.g., returningErrCodeNotInDic). This is a runtime behavior regression because a previously supported error code is now unmapped. [ Low confidence ]protocolErrorsDictionaryomits the previously supported selector"0x7e273289"for theERC721InvalidOwnererror. In the prior version (see removed mapping in the diff), both"0x89c62b64"and"0x7e273289"were mapped toERC721InvalidOwner. After this change, only"0x89c62b64"remains. Any lookup by code"0x7e273289"will now fail to resolve and will likely fall through to an error such asErrCodeNotInDic, causing a runtime behavior change for valid inputs that previously resolved correctly. [ Low confidence ]protocolErrorsDictionarydropped the mapping for the error code"0x7e273289"corresponding toERC721InvalidOwner(address). In the previous implementation, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner(address owner). In the new implementation, only"0x89c62b64"is present. Any runtime lookup of"0x7e273289"will now fail to resolve to a known error and likely result in a fallback (e.g., returningErrCodeNotInDic), causing incorrect behavior when decoding protocol error messages containing this code. [ Low confidence ]protocolErrorsDictionaryno longer includes the alias key"0x7e273289"forERC721InvalidOwner, which existed in the previous implementation. If upstream inputs can contain this error code (which is plausible given it was present before), lookups will now fail to resolve and will likely surface asErrCodeNotInDicor equivalent fallback behavior elsewhere. This is a functional regression in error decoding: previously both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, but now only"0x89c62b64"is present. The omission creates a reachable runtime path where a valid protocol error code is not recognized. [ Low confidence ]"0x3c355a89"), buttryExtractProtocolError's regex allows uppercase hex digits and performs a direct, case-sensitive lookup without normalizing the matched code. If an upstream error contains an uppercase selector (e.g.,0xABCDEF01),protocolErrorsDictionary[matches[1]]will miss and returnErrCodeNotInDiceven when the selector exists. Normalize the matched selector (e.g.,strings.ToLower(matches[1])) before lookup to avoid false negatives. [ Low confidence ]protocolErrorsDictionaryin this commit no longer includes the mapping for selector"0x7e273289"which previously mapped to"ERC721InvalidOwner(address owner)". The new dictionary only includes"0x89c62b64": ErrERC721InvalidOwner. If upstream error messages use either selector (e.g., due to multiple contract versions emitting different selectors), lookups for"0x7e273289"will now fail (likely resulting inErrCodeNotInDicfrom consuming code), breaking contract parity with the previous behavior and causing a runtime failure to decode/normalize certain ERC721 errors. [ Low confidence ]protocolErrorsDictionaryremoved the mapping for the error code"0x7e273289"that previously pointed toERC721InvalidOwner(...). The new dictionary only includes"0x89c62b64": ErrERC721InvalidOwner. If upstream inputs can produce0x7e273289(as they could before this change), lookups will now fail with a "code not found" path (e.g.,ErrCodeNotInDic), causing a runtime behavior change and loss of coverage for a valid protocol error. This is a contract-parity regression: previously both selectors were recognized; now one is missing. [ Low confidence ]"0x7e273289"forERC721InvalidOwner(address owner)was present in the prior mapping but is missing from the newprotocolErrorsDictionarymap. In the current code, only"0x89c62b64"maps toErrERC721InvalidOwner. If upstream revert data includes"0x7e273289"(which the previous version explicitly handled), lookups will now fail and callers will receiveErrCodeNotInDic(or equivalent not-found handling), causing a runtime behavior regression and loss of error translation. This is an externally visible contract change: previously both codes were recognized; now one is silently dropped. [ Low confidence ]protocolErrorsDictionarychanged frommap[string]string(human-readable messages with parameter names) tomap[string]errorpointing to preconstructederrorvalues whoseError()strings now omit parameter names (e.g.,"InvalidPayloadSize(uint256,uint256,uint256)"instead of"InvalidPayloadSize(uint256 actualSize_, uint256 minSize_, uint256 maxSize_)"). This is an externally visible contract change: any code that relies on the previous string messages (for display, parsing, or matching) will now receiveerrorvalues with different text, which can cause runtime mismatches in formatting, parsing, or downstream logic that expects names. Even if callers compare by selector-to-string, this change alters the semantics and may break message parsing/validation at runtime. [ Low confidence ]protocolErrorsDictionaryno longer includes the mapping for the error code"0x7e273289"that previously corresponded toERC721InvalidOwner. This regression means that if a contract emits the selector0x7e273289, a lookup againstprotocolErrorsDictionarywill fail and likely produceErrCodeNotInDicat runtime. Since both0x89c62b64and0x7e273289have historically been used forERC721InvalidOwner, removing0x7e273289reduces compatibility and introduces a runtime functional bug for inputs producing that error code. [ Low confidence ]protocolErrorsDictionarychanged frommap[string]string(human-readable messages including parameter names) tomap[string]errorwithfmt.Errorfvalues whoseError()strings omit parameter names. Even where the mapping exists, consumers that rely on exact message strings (e.g., for matching, display with parameter names, or tests) will now see different text. If the consuming code compares strings or expects the parameter-name-rich messages, this change yields different runtime behavior and may cause logic or test failures at runtime (beyond any compile-time type mismatch in some call sites). [ Low confidence ]protocolErrorsDictionarychanged frommap[string]stringtomap[string]error. This is a contract change for any callers expecting string values (e.g., for logging or further parsing). If downstream code still treats dictionary values as strings or performs string-specific operations without adaptation, it can cause runtime errors or altered behavior (such as printing a genericerrorstring instead of the original descriptive message with parameter names). Even if compilation elsewhere adapts, the observable error messages have changed (parameter names are removed), which may break consumers relying on exact messages. [ Low confidence ]protocolErrorsDictionaryno longer includes a mapping for the error selector"0x7e273289"which previously corresponded toERC721InvalidOwner(address owner). This omission means that any upstream lookup of this known selector will fail to resolve to a protocol error and will likely surface asErrCodeNotInDicor equivalent handling, causing a runtime failure to decode/interpret the error. All other previously-present selectors appear preserved; this one was dropped in the transition from string messages toerrorvalues. [ Low confidence ]protocolErrorsDictionaryno longer contains the previously present selector mapping for the secondERC721InvalidOwnerselector ("0x7e273289"). In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner(...)variants; after the change, only"0x89c62b64"remains. If on-chain revert data includes"0x7e273289", a lookup againstprotocolErrorsDictionarywill now fail and likely result in a fallback path (e.g., returningErrCodeNotInDic). This is a runtime behavior regression that causes valid revert reasons to be unrecognized. [ Low confidence ]protocolErrorsDictionaryno longer includes the mapping for the error selector"0x7e273289"(previously mapped to"ERC721InvalidOwner(address owner)"). This omission means that if a revert uses this selector, lookups inprotocolErrorsDictionarywill fail and can surfaceErrCodeNotInDicat runtime. In the prior version, both"0x89c62b64"and"0x7e273289"were present; the latter has been dropped, creating a real runtime gap when decoding protocol errors. [ Low confidence ]map[string]stringwith human-readable messages including parameter names (e.g.,"ERC721IncorrectOwner(address sender, uint256 tokenId, address owner)") tomap[string]errorwith simplified error strings (e.g.,"ERC721IncorrectOwner(address,uint256,address)") reduces diagnostic fidelity and may break any runtime consumers that parse or rely on the detailed message format. This is an externally visible contract change: callers previously received detailed strings; now they receiveerrorvalues with shortened messages lacking parameter names and sometimes altered capitalization (e.g.,UnsupportedChainId). If downstream logic matches on message content or surfaces it to users, the behavior will change at runtime, potentially leading to mis-parsing or less informative error reporting. [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"which previously mapped to the same semantic error asErrERC721InvalidOwner(an alternate selector forERC721InvalidOwner). This omission means that when this valid error code is encountered, lookup will fail and downstream logic will likely surfaceErrCodeNotInDic(or otherwise fail to resolve the error), breaking parity with prior behavior that successfully recognized this selector. Add back the entry"0x7e273289": ErrERC721InvalidOwnerto preserve complete coverage of known protocol error codes. [ Low confidence ]protocolErrorsDictionarypreviously included a mapping for the error code"0x7e273289"(forERC721InvalidOwner(address owner)), but the new dictionary omits that key. With reachable inputs containing that code,tryExtractProtocolErrorwill now returnErrCodeNotInDicinstead of a decoded protocol error, changing externally visible behavior and causing callers that rely on decoding this specific error code to receive a failure. This is a runtime behavior change for valid inputs and breaks parity with previously supported protocol codes. [ Low confidence ]protocolErrorsDictionarychanged type frommap[string]stringof full error signatures with parameter names tomap[string]errorwith shortened signatures lacking parameter names (e.g.,"InvalidPayloadSize(uint256,uint256,uint256)"vs previous"InvalidPayloadSize(uint256 actualSize_, uint256 minSize_, uint256 maxSize_)"). At runtime, callers that compare or log exact revert signature strings will now see different messages, potentially breaking string-based matching, alerts, or user-facing diagnostics. [ Low confidence ]"0x7e273289"toERC721InvalidOwner(address owner)but the newprotocolErrorsDictionaryomits this key entirely. If the chain emits this revert selector, lookups intoprotocolErrorsDictionarywill now fail and likely resolve toErrCodeNotInDic, causing incorrect error reporting at runtime. [ Low confidence ]protocolErrorsDictionaryno longer includes the error code"0x7e273289"forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, but after the change only"0x89c62b64"remains. If the protocol or upstream emits"0x7e273289", lookups will fail, likely resulting in a fallback error (e.g.,ErrCodeNotInDic) and incorrect behavior. This is a runtime contract regression in error-code coverage. [ Low confidence ]protocolErrorsDictionaryno longer contains the previously supported error code key"0x7e273289"(an alternate selector forERC721InvalidOwner). In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner. After the change tomap[string]error,"0x7e273289"was dropped, leaving only"0x89c62b64". Any runtime path that encounters error code"0x7e273289"will now fail to resolve a known protocol error (likely falling back to a generic error such asErrCodeNotInDic). This is a contract-parity regression for error decoding and can cause incorrect or degraded behavior when parsing on-chain revert/error messages. [ Low confidence ]protocolErrorsDictionary: the key"0x7e273289"that previously mapped toERC721InvalidOwner(address owner)has been removed. The new dictionary includes only"0x89c62b64": ErrERC721InvalidOwner. If upstream code receives error selector0x7e273289(which was present in the prior version), lookups will now fail and likely fall back toErrCodeNotInDicor equivalent handling, changing runtime behavior for a previously supported error code. [ Low confidence ]"0x7e273289"mapping toERC721InvalidOwner(address owner)was present in the prior version but is missing from the updatedprotocolErrorsDictionary. Only"0x89c62b64": ErrERC721InvalidOwnerremains. If upstream code encounters the0x7e273289selector (which the previous code recognized), lookups intoprotocolErrorsDictionarywill now fail and likely trigger fallback handling (e.g.,ErrCodeNotInDic). This is a functional regression and a runtime behavior change for inputs that were previously handled. [ Low confidence ]protocolErrorsDictionarytype changed frommap[string]stringtomap[string]error, and many error messages now omit parameter names (e.g.,"InvalidPayloadSize(uint256,uint256,uint256)"instead of"InvalidPayloadSize(uint256 actualSize_, uint256 minSize_, uint256 maxSize_)"). If any downstream code relies on the string values for display, matching, or regex-based parsing (hinted by the presence ofErrCompileRegex), this change can cause runtime misclassification or parsing failures without compilation errors. It is an externally visible contract change: callers retrieving dictionary values will now receive error instances and altered message content. [ Low confidence ]protocolErrorsDictionarydrops a previously supported error code"0x7e273289"forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"were mapped to the "invalid owner" condition. The new map includes only"0x89c62b64": ErrERC721InvalidOwnerand omits"0x7e273289". If upstream error data contains the omitted code, lookups will fail, leading to mismapped or unhandled errors at runtime. To preserve contract parity, add a mapping for"0x7e273289"pointing toErrERC721InvalidOwner. [ Low confidence ]protocolErrorsDictionarychanged type frommap[string]stringtomap[string]error, and the values changed from human-readable messages (including parameter names) to pre-constructederrorvalues with simplified signatures. Any in-package consumer that previously relied on string content (e.g., string comparison, JSON marshaling, or extracting parameter names) will now either fail at compile time or exhibit different runtime behavior (e.g., comparing strings vs. comparingerrorvalues, or losing parameter names). Even ignoring compile errors, code paths that check for specific messages at runtime or serialize these messages will now produce different output. [ Compilation Issue ]protocolErrorsDictionarypreviously included a mapping for the error selector"0x7e273289"toERC721InvalidOwner(...). In the updated code, this selector is no longer present in themap[string]error, leaving"0x7e273289"unmapped. Any runtime that encounters this selector will fail to resolve it viaprotocolErrorsDictionaryand likely fall back toErrCodeNotInDic, changing externally visible behavior for that error case. You should add"0x7e273289": ErrERC721InvalidOwnerto restore parity with prior behavior. [ Low confidence ]protocolErrorsDictionaryhas changed frommap[string]stringtomap[string]error(now mapping codes to pre-declarederrorvalues). This is an externally visible contract change for a package-level variable. Any existing callers that expect string values (e.g., perform string concatenation, substring checks, or JSON serialization of the mapped message) will now receiveerrorand may panic or misbehave at runtime when attempting string-specific operations. This can cause runtime type assertion failures or incorrect behavior if not updated everywhere that consumes the dictionary. [ Low confidence ]"0x7e273289"(previously associated withERC721InvalidOwner) has been removed fromprotocolErrorsDictionary. If this selector is still emitted by upstream protocols/contracts, lookups will fail and code will likely returnErrCodeNotInDicor an equivalent fallback, resulting in incorrect error classification at runtime. This is a contract-parity risk against previously supported inputs. [ Low confidence ]protocolErrorsDictionarychanged frommap[string]stringtomap[string]error, altering the external contract of this package-level variable. Any existing callers that expect a string description (e.g., for logging, formatting, concatenation, or regex matching) will now receive anerrorand may fail at runtime (type assertion errors, panics, or malformed outputs) if they are not updated accordingly. This is a runtime behavior change and can break consumers of this map. [ Low confidence ]protocolErrorsDictionaryomits the previously supported error code"0x7e273289"forERC721InvalidOwner(address). In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, but the updated map retains only"0x89c62b64". Any revert or error message carrying the selector"0x7e273289"will no longer resolve to a known error and will likely result inErrCodeNotInDic(or equivalent downstream handling), causing a behavioral regression and making a previously valid input path reach an error outcome. [ Low confidence ]protocolErrorsDictionaryno longer includes the revert code"0x7e273289"forERC721InvalidOwner. In the previous version, both"0x89c62b64"and"0x7e273289"were mapped toERC721InvalidOwner, but the updated dictionary only contains"0x89c62b64". If upstream logic attempts to decode"0x7e273289"(which has existed historically in some ERC721 implementations), the lookup will fail and likely produceErrCodeNotInDicor equivalent fallback behavior, changing runtime behavior from a successful decode to an error. This is a runtime bug when that code is encountered. [ Low confidence ]"0x7e273289"(previously mapped to"ERC721InvalidOwner(address owner)") present in the prior version was removed in the newprotocolErrorsDictionary. In the current code, only"0x89c62b64"maps toErrERC721InvalidOwner. Any lookup that encounters revert code"0x7e273289"will now fail to resolve to a known error and will likely surface asErrCodeNotInDicor equivalent in calling code, changing externally visible behavior and causing unrecognized errors at runtime. [ Low confidence ]protocolErrorsDictionarypreviously included a mapping for the error code"0x7e273289"toERC721InvalidOwner(...)but this entry was removed in the new dictionary. If the upstream protocol still emits"0x7e273289", lookups intoprotocolErrorsDictionarywill now fail, leading to a runtime path that likely returnsErrCodeNotInDicinstead of the intended sentinel error (or previous string). This is a runtime behavior change and can cause unhandled or misclassified errors at runtime for that code. [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"forERC721InvalidOwner. In the previous version, both"0x89c62b64"and"0x7e273289"mapped to theERC721InvalidOwner(...)signature, but the new map retains only"0x89c62b64". Any error decoding path that encounters on-chain error selector0x7e273289will now fail to resolve to a known error and likely fall back to a generic or "not found" path (e.g.,ErrCodeNotInDic), changing behavior and potentially breaking error handling for that case. [ Low confidence ]"0x7e273289"forERC721InvalidOwner(address owner)was present in the previous dictionary and is now missing fromprotocolErrorsDictionary. The new map includes only"0x89c62b64": ErrERC721InvalidOwner. Any revert matching selector0x7e273289will now be unmapped, causing lookups to fail (e.g., returning a genericErrCodeNotInDicor equivalent in upstream logic), which is a runtime regression in error decoding. [ Low confidence ]protocolErrorsDictionaryno longer includes the previously present selector key"0x7e273289"forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped to"ERC721InvalidOwner(address owner)". After the change, only"0x89c62b64"maps toErrERC721InvalidOwner, and the"0x7e273289"entry was removed. If upstream error messages contain the0x7e273289selector (e.g., from a different Solidity compiler or library version emitting the alternate signature ID), lookups inprotocolErrorsDictionarywill fail and fall through toErrCodeNotInDicat runtime. This is a reachable runtime behavior change caused by the diff and breaks contract parity with the previous mapping set. [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"forERC721InvalidOwner. In the previous implementation, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner(address owner). After the change tomap[string]error, only"0x89c62b64"remains. Any runtime path that receives the"0x7e273289"error code will not be recognized and will likely fall back toErrCodeNotInDic, causing incorrect error handling for valid on-chain errors. [ Low confidence ]protocolErrorsDictionaryno longer contains an entry for the error selector"0x7e273289", which previously mapped toERC721InvalidOwner. The current map only includes"0x89c62b64": ErrERC721InvalidOwner. Any code that encounters the selector0x7e273289will now fail to resolve to a known error and will likely fall back to a generic path (e.g., returningErrCodeNotInDic), changing runtime behavior for that input. This is a functional regression from the prior dictionary which supported both selectors. [ Low confidence ]ERC721InvalidOwner(...):"0x89c62b64"and"0x7e273289". In the updatedprotocolErrorsDictionary(nowmap[string]error), the entry for"0x7e273289"was removed, leaving only"0x89c62b64": ErrERC721InvalidOwner. This removal breaks contract parity with prior behavior and creates a reachable runtime path where an error containing selector"0x7e273289"will no longer be mapped, potentially causing downstream handling to fall back toErrCodeNotInDicor equivalent, changing observable behavior for valid inputs. [ Low confidence ]protocolErrorsDictionarycoverage: the previous implementation included two distinct selectors forERC721InvalidOwner(...):"0x89c62b64"and"0x7e273289". In the updated map, only"0x89c62b64"remains and the"0x7e273289"entry was removed. If on-chain reverts emit the"0x7e273289"selector, lookup will fail and any code relying on mapping to a canonical error will seeErrCodeNotInDicor equivalent fallback instead of the expected error. This is a functional runtime bug because valid inputs (error code0x7e273289) now terminate in an incorrect outcome (unmapped). [ Low confidence ]protocolErrorsDictionaryremoved the alternate error code mapping forERC721InvalidOwner. In the previous version, both"0x89c62b64"and"0x7e273289"were mapped to theERC721InvalidOwnererror (the old map included a second entry for the same semantic error). In the updated map, only"0x89c62b64"remains. If upstream components encounter the other valid revert selector"0x7e273289"(which previously resolved correctly), lookups will now fail and likely fall back to a generic or unknown error path at runtime. This is an externally visible behavioral regression in error decoding/normalization and can cause incorrect error handling or user messaging when the removed selector is emitted. [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"forERC721InvalidOwner, which previously existed in the old mapping. The current code only maps"0x89c62b64"toErrERC721InvalidOwner. If upstream error messages contain"0x7e273289", lookups will fail and the code will return a fallback (e.g.,ErrCodeNotInDic), causing incorrect behavior at runtime when trying to interpret on-chain errors. This is a regression from the prior behavior that supported both selectors. [ Low confidence ]protocolErrorsDictionaryno longer contains the previously-present key"0x7e273289"forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, but the new map only includes"0x89c62b64". Any runtime path that parses an error code of0x7e273289will now fail to resolve to a known error and will likely fall back to a generic error (e.g.,ErrCodeNotInDic), changing behavior and potentially failing error handling logic that expects this code to be recognized. [ Low confidence ]protocolErrorsDictionaryno longer includes the code"0x7e273289"forERC721InvalidOwner. In the previous version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, but the new map only keeps"0x89c62b64". If upstream error decoding receives"0x7e273289", it will fail to find a matching entry and will likely fall back toErrCodeNotInDic, creating a runtime mismatch for valid protocol errors. Add a mapping for"0x7e273289"toErrERC721InvalidOwnerto preserve behavior and handle all known variants. [ Low confidence ]protocolErrorsDictionarymapping omits the previously supported error code"0x7e273289"forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, whereas the new map only includes"0x89c62b64": ErrERC721InvalidOwner. If upstream inputs include"0x7e273289"(which was formerly recognized), lookups will fail and will likely resolve toErrCodeNotInDic, altering runtime behavior and causing previously handled errors to be treated as unknown. This is a contract parity regression for error-code coverage. [ Low confidence ]"0x7e273289"forERC721InvalidOwner(address owner), which is missing in the newprotocolErrorsDictionary. The current map only contains"0x89c62b64": ErrERC721InvalidOwner. If the blockchain can emit either hash, the absence of"0x7e273289"will cause lookups for that code to fail and likely be treated asErrCodeNotInDicor otherwise unrecognized, resulting in incorrect error handling at runtime. [ Low confidence ]protocolErrorsDictionarylost support for the error code selector"0x7e273289"that previously mapped toERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped to the same semantic error (two known selectors). In the new map only"0x89c62b64"remains (line near the existing mapping toErrERC721InvalidOwner). Any upstream logic that decodes revert data containing the"0x7e273289"selector will now fail to find it in the dictionary and likely returnErrCodeNotInDicor equivalent fallback, causing incorrect runtime behavior for valid inputs that used to be handled. You should re-add"0x7e273289": ErrERC721InvalidOwnertoprotocolErrorsDictionary. [ Low confidence ]protocolErrorsDictionaryno longer includes the alternate selector"0x7e273289"for theERC721InvalidOwnererror (previously present in the old dictionary). If upstream error decoding emits this selector, lookup will fail and any logic depending on mapping the code to an error will fall back toErrCodeNotInDic(or equivalent), causing incorrect runtime behavior. Add"0x7e273289": ErrERC721InvalidOwnerto preserve support for both selectors. [ Low confidence ]protocolErrorsDictionarypreviously contained a mapping for the selector"0x7e273289"to an ERC721 invalid owner error string. In the new code, only"0x89c62b64": ErrERC721InvalidOwnerremains and the"0x7e273289"mapping has been removed entirely. If upstream logic encounters the0x7e273289error selector (which was present before), looking it up inprotocolErrorsDictionarywill now fail and likely produceErrCodeNotInDicor equivalent fallback, changing runtime behavior and potentially breaking error decoding for ERC721 invalid owner reverts that use that alternate selector. This is a contract-parity regression in the error-decoding table. [ Low confidence ]protocolErrorsDictionaryno longer includes the previously mapped error code"0x7e273289"forERC721InvalidOwner. In the old version, both"0x89c62b64"and"0x7e273289"were mapped toERC721InvalidOwner, but the new map only includes"0x89c62b64". If the protocol emits"0x7e273289", lookups will now fail (likely resulting inErrCodeNotInDicdownstream), breaking contract parity with prior behavior. Add the missing"0x7e273289"mapping to preserve coverage for all known protocol error codes. [ Low confidence ]protocolErrorsDictionaryomits a selector that previously mapped toERC721InvalidOwner. In the prior version there were two distinct selectors forERC721InvalidOwner:"0x89c62b64"and"0x7e273289". In the updated code, only"0x89c62b64"is present. Any runtime lookup for error code"0x7e273289"will now fail (likely resulting inErrCodeNotInDicdownstream) even though it was handled before. This is a regression in error-code coverage. [ Low confidence ]protocolErrorsDictionaryomits the previously present mapping for the selector"0x7e273289"(an alternate selector forERC721InvalidOwner). In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner. After the change, only"0x89c62b64"is present. If upstream emits"0x7e273289", a lookup will now return the zero value (anilerror), likely resulting in silent success or fallback handling (ErrCodeNotInDic) depending on the consumer logic, which is a behavioral regression and a runtime bug in error normalization. This violates contract parity by dropping support for a previously recognized error code. [ Low confidence ]protocolErrorsDictionaryomits the selector"0x7e273289"forERC721InvalidOwner. In the previous version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner. Removing"0x7e273289"introduces a runtime gap: lookups performed with this valid error code will fail and fall back to a "not found" outcome (e.g.,ErrCodeNotInDic), breaking error decoding for contracts that emit the alternate selector. This is a functional regression in error mapping coverage. [ Low confidence ]"0x7e273289"to the ERC721 invalid owner error. In the updatedprotocolErrorsDictionary(nowmap[string]error), the mapping for"0x7e273289"has been removed, and only"0x89c62b64": ErrERC721InvalidOwnerremains. If upstream errors contain the code0x7e273289,tryExtractProtocolErrorwill now returnErrCodeNotInDicinstead of the appropriateErrERC721InvalidOwnererror. This is a runtime behavior regression/compatibility bug that can cause valid protocol errors to be misclassified as unknown. [ Low confidence ]protocolErrorsDictionaryno longer includes the key"0x7e273289"for theERC721InvalidOwnererror, which existed in the previous version. If this error code is emitted by the protocol (as the earlier map suggests), lookups for this valid code will now fail, likely resulting inErrCodeNotInDicbehavior upstream. To fix, restore the missing mapping:"0x7e273289": ErrERC721InvalidOwner. [ Low confidence ]protocolErrorsDictionary(typemap[string]error) omits a previously present mapping for the error selector"0x7e273289", which was an alias forERC721InvalidOwner(address owner). In the prior code, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner. After the change, only"0x89c62b64"remains. If upstream error decoding encounters"0x7e273289"(still a valid on-chain selector emitted by some contracts), lookups will fail and likely surface asErrCodeNotInDic(or equivalent fallback), causing a runtime behavior regression where a known error is no longer recognized. This is a runtime bug because a valid, previously supported error code becomes unrecognized. [ Low confidence ]protocolErrorsDictionaryremoved a previously supported selector forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped to theERC721InvalidOwnererror. In the updated code, only"0x89c62b64"is present and"0x7e273289"is missing. If on-chain errors include the"0x7e273289"selector, lookups will fail, causing downstream logic that relies on this dictionary to be unable to decode the error and likely returnErrCodeNotInDicor an equivalent fallback. This is a runtime behavioral regression and breaks contract parity for previously handled inputs. [ Low confidence ]protocolErrorsDictionaryomits a previously supported error code"0x7e273289"forERC721InvalidOwner. In the prior mapping (pre-diff), both"0x89c62b64"and"0x7e273289"were present and mapped toERC721InvalidOwner(address owner). After the change, only"0x89c62b64"is mapped toErrERC721InvalidOwner, and"0x7e273289"is no longer present. Any upstream code that extracts error codes from revert data and looks them up in this dictionary will now fail to resolve"0x7e273289", potentially resulting in a fallback path (e.g., returningErrCodeNotInDicor equivalent) instead of the correct canonical error. This is a contract parity regression: the externally visible behavior for decoding error codes no longer recognizes a previously supported code variant. [ Low confidence ]ERC721InvalidOwner, specifically"0x89c62b64"and"0x7e273289". In the updatedprotocolErrorsDictionary(nowmap[string]error), only"0x89c62b64"is present and"0x7e273289"was removed. If upstream code attempts to translate an on-chain error encoded with selector"0x7e273289", it will not be found in the dictionary and will likely fall back to an error path (e.g.,ErrCodeNotInDic). This is an externally visible behavioral regression and a runtime issue because valid, previously handled on-chain errors will now be unrecognized. [ Low confidence ]protocolErrorsDictionarypreviously contained two distinct codes forERC721InvalidOwner("0x89c62b64"and"0x7e273289"). In the updated map, the entry for"0x7e273289"is missing while"0x89c62b64"remains. If upstream protocol messages can still emit error code"0x7e273289", lookups will fail and callers will likely fall back toErrCodeNotInDic, causing incorrect error handling at runtime. This is a regression in the dictionary coverage and can lead to misclassification of errors. [ Low confidence ]protocolErrorsDictionarymap omits the previously supported selector"0x7e273289"forERC721InvalidOwner(address), which was present before the change. Now only"0x89c62b64": ErrERC721InvalidOwneris included. If the protocol can emit either of these selectors, lookups for"0x7e273289"will fail and any code relying on this dictionary may returnErrCodeNotInDicor otherwise mis-handle the error, causing a runtime behavior regression for those inputs. [ Low confidence ]protocolErrorsDictionaryincluded two distinct selector keys forERC721InvalidOwner:"0x89c62b64"and"0x7e273289". In the new code, only"0x89c62b64": ErrERC721InvalidOwnerremains, and the mapping for"0x7e273289"has been removed. If upstream contracts can still emit the0x7e273289selector, lookups intoprotocolErrorsDictionarywill now fail, likely resulting inErrCodeNotInDicor equivalent fallback paths at runtime. This is a behavior regression and can cause previously handled errors to become unrecognized. [ Low confidence ]protocolErrorsDictionaryomits the known selector"0x7e273289"forERC721InvalidOwnerthat existed prior to the change. In the previous implementation, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner(address owner). After this change, only"0x89c62b64"is present, which creates a runtime mismatch: any error message containing"0x7e273289"will now fail to resolve to a known error and will likely fall through to a generic handling path (e.g., returningErrCodeNotInDic). This is a regression in the error-code-to-error mapping and can cause incorrect behavior or degraded error reporting when encountering that selector. [ Low confidence ]ERC721InvalidOwnerpreviously included two different error selectors ("0x89c62b64"and"0x7e273289") for the same Solidity error signature, but in the updatedprotocolErrorsDictionaryonly"0x89c62b64"is present. If the protocol can emit the alternative selector"0x7e273289", lookups will now fail and return a fallback (e.g.,ErrCodeNotInDic) rather than the intended error. This is a runtime behavior regression because a valid revert code may no longer be recognized. [ Low confidence ]protocolErrorsDictionaryomits the previously present key"0x7e273289"that mapped toERC721InvalidOwner(...). In the prior implementation, both"0x89c62b64"and"0x7e273289"were recognized as variants ofERC721InvalidOwner. The new dictionary only includes"0x89c62b64": ErrERC721InvalidOwnerand drops"0x7e273289". Any code that translates on-chain error messages using that signature hash will now fail to resolve this error and will likely fall back toErrCodeNotInDicor another generic path, causing a behavior regression. This is a concrete, externally visible runtime behavior change introduced by the diff. [ Low confidence ]protocolErrorsDictionaryincluded two distinct selector keys forERC721InvalidOwner:"0x89c62b64"and"0x7e273289". In the updated code, only"0x89c62b64"is present and"0x7e273289"has been removed. If upstream inputs include the removed selector ("0x7e273289"), lookups inprotocolErrorsDictionarywill fail, causing a "code not found" behavior (e.g., returningErrCodeNotInDic) where a valid mapping existed previously. This is an externally visible contract regression and can lead to runtime handling failures for that error selector. [ Low confidence ]protocolErrorsDictionarymapping dropped support for the ERC721InvalidOwnererror selector"0x7e273289"that was present before the diff. In the old mapping there were two selectors forERC721InvalidOwner(address owner):"0x89c62b64"and"0x7e273289". In the new mapping only"0x89c62b64"remains. Any upstream logic that receives revert data corresponding to selector"0x7e273289"will no longer be recognized and will likely fall through to a generic error path (e.g.,ErrCodeNotInDic) rather than correctly mapping toErrERC721InvalidOwner. This is a behavioral/runtime compatibility issue, not a compilation error. [ Low confidence ]protocolErrorsDictionaryno longer includes the alternative selector key"0x7e273289"that previously mapped toERC721InvalidOwner(address owner). Only"0x89c62b64": ErrERC721InvalidOwnerremains. If any upstream contracts emit theERC721InvalidOwnererror with the removed selector, lookups will now fail at runtime (e.g., yielding a "not found" outcome viaErrCodeNotInDicin callers). This is an externally visible behavior change that can cause valid revert codes to be silently unmapped and mishandled. [ Low confidence ]protocolErrorsDictionarylost a previously supported selector key for the sameERC721InvalidOwnererror. In the prior version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner(address owner). After the change, only"0x89c62b64"remains, and"0x7e273289"is no longer present. If upstream error decoding can produce"0x7e273289"(e.g., from a different compiler/encoding variant or contract version), lookups will fail, likely yielding a nil result or a fallback error such asErrCodeNotInDic. This is a runtime behavior regression and a contract-parity break in error decoding. The fix is to add back the missing mapping:"0x7e273289": ErrERC721InvalidOwner. [ Low confidence ]InvalidOwnererror is missing the previously present error code key"0x7e273289". Only"0x89c62b64"is mapped toErrERC721InvalidOwner. If on-chain revert data uses0x7e273289, lookup intoprotocolErrorsDictionarywill fail and likely result inErrCodeNotInDicdownstream, causing incorrect error handling for a valid protocol error. [ Low confidence ]protocolErrorsDictionarymapping no longer includes the previously present key"0x7e273289"for theERC721InvalidOwnererror. The prior version mapped both"0x89c62b64"and"0x7e273289"toERC721InvalidOwner(...). After the change, only"0x89c62b64"is mapped (toErrERC721InvalidOwner). If the blockchain emits the error code"0x7e273289", lookups againstprotocolErrorsDictionarywill fail and callers relying on a successful mapping will experience a runtime error condition (e.g., returningErrCodeNotInDicor equivalent). This is a contract parity bug: the set of supported protocol error codes has been reduced, potentially causing previously working inputs to become unrecognized. [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"forERC721InvalidOwner(address owner), which existed before the change. Now only"0x89c62b64": ErrERC721InvalidOwneris present. If upstream code encounters on-chain errors with selector0x7e273289, lookups will fail and likely surfaceErrCodeNotInDicat runtime instead of the intended mapped error. [ Low confidence ]protocolErrorsDictionaryno longer includes the previously supported error code"0x7e273289"forERC721InvalidOwner. In the prior version, both"0x89c62b64"and"0x7e273289"mapped to the ERC721 invalid owner error signature. In the updated code, only"0x89c62b64"remains (mapping toErrERC721InvalidOwneratprotocolErrorsDictionary["0x89c62b64"]), and the"0x7e273289"entry was removed. If upstream logic relies on decoding this selector from revert data, inputs that carry"0x7e273289"will no longer be recognized and will likely fall through to a generic path (e.g.,ErrCodeNotInDic), changing externally visible behavior and causing incorrect error handling at runtime. [ Low confidence ]protocolErrorsDictionaryremoved a previously supported error code mapping forERC721InvalidOwner. In the original map there was an entry for"0x7e273289"(also mapped toERC721InvalidOwner(address owner)), but in the updated map only"0x89c62b64": ErrERC721InvalidOwnerremains. If upstream inputs can still emit the0x7e273289code, lookups will now fail and downstream logic may incorrectly treat the error as unknown (e.g., returningErrCodeNotInDic). This is a runtime behavior regression caused by the diff, not a compile-time issue. [ Low confidence ]protocolErrorsDictionaryremoves the previously present mapping for the error code"0x7e273289"which also representedERC721InvalidOwner. The old dictionary had two distinct selectors forERC721InvalidOwner("0x89c62b64"and"0x7e273289"). The new dictionary only includes"0x89c62b64": ErrERC721InvalidOwnerand omits"0x7e273289". If upstream inputs contain the missing selector, lookups will fail (e.g., returning a default or causing fallback toErrCodeNotInDic), resulting in incorrect error normalization at runtime. To fix, reintroduce the"0x7e273289"key pointing toErrERC721InvalidOwner. [ Low confidence ]protocolErrorsDictionaryomits the selector"0x7e273289"that previously mapped toERC721InvalidOwner(...). In the prior version, both"0x89c62b64"and"0x7e273289"were mapped to the same logical error. After this change, only"0x89c62b64"is present. If upstream error decoding encounters"0x7e273289", lookup intoprotocolErrorsDictionarywill fail, likely resulting in a generic or incorrect error (e.g.,ErrCodeNotInDic). This is a runtime behavior regression for any chain/contracts that return the alternate selector. [ Low confidence ]protocolErrorsDictionaryremoved support for the error selector"0x7e273289"which previously mapped to"ERC721InvalidOwner(address owner)". In the new map, only"0x89c62b64"is mapped toErrERC721InvalidOwner. If contracts can emit both selectors, inputs containing"0x7e273289"will now fail lookup and likely fall back toErrCodeNotInDic, causing incorrect behavior. Add"0x7e273289": ErrERC721InvalidOwnerto preserve parity with the prior behavior. [ Low confidence ]protocolErrorsDictionaryno longer includes the selector"0x7e273289"forERC721InvalidOwner. In the previous version, both"0x89c62b64"and"0x7e273289"mapped toERC721InvalidOwner, but the new map only includes"0x89c62b64". If on-chain errors are emitted with"0x7e273289", lookup will fail and downstream code will receive a fallback (e.g.,ErrCodeNotInDic) or otherwise mis-handle the error. This is a runtime behavior gap where a previously supported code becomes unmapped. [ Low confidence ]"0x7e273289"(a variant ofERC721InvalidOwner) that existed in the previousprotocolErrorsDictionaryhas been removed in the new mapping. The old dictionary had two codes forERC721InvalidOwner("0x89c62b64"and"0x7e273289"), but the newmap[string]erroronly includes"0x89c62b64". Any runtime lookup for"0x7e273289"will now fail to resolve to the intended error and will likely result in a fallback such asErrCodeNotInDic. This reduces coverage and can misclassify on-chain error decodes for valid inputs. [ Low confidence ]protocolErrorsDictionarypreviously included two selectors forERC721InvalidOwner, including"0x7e273289", but the new map only includes"0x89c62b64"and drops"0x7e273289". If on-chain errors are emitted using the0x7e273289selector, lookups intoprotocolErrorsDictionarywill fail, likely leading toErrCodeNotInDicbeing returned downstream. This is a functional regression and a runtime bug whenever that selector appears in inputs. [ Low confidence ]