Skip to content

Conversation

@fbac
Copy link
Collaborator

@fbac fbac commented Oct 9, 2025

Return typed blockchain protocol errors and update pkg/blockchain error handling to support errors.Is/As

Introduce package-level typed protocol errors and refactor error handling to propagate and unwrap them throughout pkg/blockchain. The protocolErrorsDictionary now maps 4-byte selectors to error values, BlockchainError carries both protocolErr and originalErr, and tryExtractProtocolError returns a typed protocol error with a separate failure indicator. Tests validate selector hashing against error signatures.

  • Update pkg/blockchain globals to define typed protocol errors and change protocolErrorsDictionary to map[string]error in errors.go
  • Refactor BlockchainError to store protocolErr and originalErr, modify Error() to prefer originalErr when extraction fails, add Unwrap() for errors.Is/As, and reimplement IsNoChange() using errors.Is in errors.go
  • Change tryExtractProtocolError to return (protocolErr error, err error) and use sentinel errors for failure cases in errors.go
  • Add TestBlockchainErrorHashes to assert keccak256-derived 4-byte selectors match dictionary keys in errors_test.go

📍Where to Start

Start with the NewBlockchainError constructor and its use of tryExtractProtocolError in 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
  • line 10: Externally visible message content change: Previously, protocolErrorsDictionary mapped codes to full human-readable strings (including parameter names, e.g., "InsufficientDeposit(uint96 amount, uint96 minimumDeposit)"). The new implementation maps codes to pre-constructed error instances 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 ]
  • line 10: Multiple error variables now use canonicalized signatures without parameter names (e.g., ErrAlreadyClaimed is "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 by ErrCompileRegex) will see different strings at runtime, potentially breaking parsing logic or degrading user-facing error detail. [ Low confidence ]
  • line 47: The error message string for ErrInvalidHTTPAddress is "InvalidHttpAddress()" (lowercase 'Http'), which does not match the canonical name implied by the variable ErrInvalidHTTPAddress and the dictionary key labeled as InvalidHTTPAddress. If any code compares error.Error() to a canonical protocol error name with uppercase HTTP, this mismatch will cause incorrect behavior (e.g., failed matching, misclassification, or broken parsing). To fix, change the message to "InvalidHTTPAddress()". [ Low confidence ]
  • line 132: The new protocolErrorsDictionary no longer includes the selector "0x7e273289" that previously mapped to "ERC721InvalidOwner(address owner)". Only "0x89c62b64": ErrERC721InvalidOwner remains. If upstream contracts or logs can emit the 0x7e273289 selector, lookups will now fail to resolve to ErrERC721InvalidOwner and will instead fall through to error handling paths for unknown codes (e.g., returning ErrCodeNotInDic elsewhere). This is a behavior regression that can lead to incorrect error decoding for valid inputs. [ Low confidence ]
  • line 132: The updated protocolErrorsDictionary no longer includes the previously present key "0x7e273289" which mapped to ERC721InvalidOwner(address owner). The new map retains only "0x89c62b64": ErrERC721InvalidOwner. This removal changes runtime behavior: any error code 0x7e273289 that was previously recognized will now be treated as unknown (e.g., consumers may return ErrCodeNotInDic). This is a contract parity break compared to the prior implementation, potentially causing misclassification or loss of detail for that error code. [ Low confidence ]
  • line 132: The protocolErrorsDictionary no longer includes a mapping for the known ERC721 error selector "0x7e273289" which previously mapped to "ERC721InvalidOwner(address owner)". In the updated code, only "0x89c62b64": ErrERC721InvalidOwner is 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., returning ErrCodeNotInDic). This is a runtime behavior regression because a previously supported error code is now unmapped. [ Low confidence ]
  • line 132: The new protocolErrorsDictionary omits the previously supported selector "0x7e273289" for the ERC721InvalidOwner error. In the prior version (see removed mapping in the diff), both "0x89c62b64" and "0x7e273289" were mapped to ERC721InvalidOwner. 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 as ErrCodeNotInDic, causing a runtime behavior change for valid inputs that previously resolved correctly. [ Low confidence ]
  • line 132: The protocolErrorsDictionary dropped the mapping for the error code "0x7e273289" corresponding to ERC721InvalidOwner(address). In the previous implementation, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner(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., returning ErrCodeNotInDic), causing incorrect behavior when decoding protocol error messages containing this code. [ Low confidence ]
  • line 132: The updated protocolErrorsDictionary no longer includes the alias key "0x7e273289" for ERC721InvalidOwner, 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 as ErrCodeNotInDic or equivalent fallback behavior elsewhere. This is a functional regression in error decoding: previously both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, but now only "0x89c62b64" is present. The omission creates a reachable runtime path where a valid protocol error code is not recognized. [ Low confidence ]
  • line 132: The protocol error dictionary keys are all lowercase hex strings (e.g., "0x3c355a89"), but tryExtractProtocolError'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 return ErrCodeNotInDic even when the selector exists. Normalize the matched selector (e.g., strings.ToLower(matches[1])) before lookup to avoid false negatives. [ Low confidence ]
  • line 132: protocolErrorsDictionary in 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 in ErrCodeNotInDic from consuming code), breaking contract parity with the previous behavior and causing a runtime failure to decode/normalize certain ERC721 errors. [ Low confidence ]
  • line 132: The updated protocolErrorsDictionary removed the mapping for the error code "0x7e273289" that previously pointed to ERC721InvalidOwner(...). The new dictionary only includes "0x89c62b64": ErrERC721InvalidOwner. If upstream inputs can produce 0x7e273289 (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 ]
  • line 132: Protocol error code "0x7e273289" for ERC721InvalidOwner(address owner) was present in the prior mapping but is missing from the new protocolErrorsDictionary map. In the current code, only "0x89c62b64" maps to ErrERC721InvalidOwner. If upstream revert data includes "0x7e273289" (which the previous version explicitly handled), lookups will now fail and callers will receive ErrCodeNotInDic (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 ]
  • line 132: The type of protocolErrorsDictionary changed from map[string]string (human-readable messages with parameter names) to map[string]error pointing to preconstructed error values whose Error() 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 receive error values 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 ]
  • line 132: The protocolErrorsDictionary no longer includes the mapping for the error code "0x7e273289" that previously corresponded to ERC721InvalidOwner. This regression means that if a contract emits the selector 0x7e273289, a lookup against protocolErrorsDictionary will fail and likely produce ErrCodeNotInDic at runtime. Since both 0x89c62b64 and 0x7e273289 have historically been used for ERC721InvalidOwner, removing 0x7e273289 reduces compatibility and introduces a runtime functional bug for inputs producing that error code. [ Low confidence ]
  • line 132: Contract parity regression: protocolErrorsDictionary changed from map[string]string (human-readable messages including parameter names) to map[string]error with fmt.Errorf values whose Error() 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 ]
  • line 132: The type of protocolErrorsDictionary changed from map[string]string to map[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 generic error string 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 ]
  • line 132: The protocolErrorsDictionary no longer includes a mapping for the error selector "0x7e273289" which previously corresponded to ERC721InvalidOwner(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 as ErrCodeNotInDic or 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 to error values. [ Low confidence ]
  • line 132: The protocolErrorsDictionary no longer contains the previously present selector mapping for the second ERC721InvalidOwner selector ("0x7e273289"). In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner(...) variants; after the change, only "0x89c62b64" remains. If on-chain revert data includes "0x7e273289", a lookup against protocolErrorsDictionary will now fail and likely result in a fallback path (e.g., returning ErrCodeNotInDic). This is a runtime behavior regression that causes valid revert reasons to be unrecognized. [ Low confidence ]
  • line 132: The protocolErrorsDictionary no 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 in protocolErrorsDictionary will fail and can surface ErrCodeNotInDic at 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 ]
  • line 132: The change from map[string]string with human-readable messages including parameter names (e.g., "ERC721IncorrectOwner(address sender, uint256 tokenId, address owner)") to map[string]error with 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 receive error values 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 ]
  • line 132: The updated protocolErrorsDictionary no longer includes the selector "0x7e273289" which previously mapped to the same semantic error as ErrERC721InvalidOwner (an alternate selector for ERC721InvalidOwner). This omission means that when this valid error code is encountered, lookup will fail and downstream logic will likely surface ErrCodeNotInDic (or otherwise fail to resolve the error), breaking parity with prior behavior that successfully recognized this selector. Add back the entry "0x7e273289": ErrERC721InvalidOwner to preserve complete coverage of known protocol error codes. [ Low confidence ]
  • line 132: Contract-parity regression: protocolErrorsDictionary previously included a mapping for the error code "0x7e273289" (for ERC721InvalidOwner(address owner)), but the new dictionary omits that key. With reachable inputs containing that code, tryExtractProtocolError will now return ErrCodeNotInDic instead 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 ]
  • line 132: Externally visible contract/behavior change: protocolErrorsDictionary changed type from map[string]string of full error signatures with parameter names to map[string]error with 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 ]
  • line 132: Missing protocol error code mapping: the previous version included a mapping for "0x7e273289" to ERC721InvalidOwner(address owner) but the new protocolErrorsDictionary omits this key entirely. If the chain emits this revert selector, lookups into protocolErrorsDictionary will now fail and likely resolve to ErrCodeNotInDic, causing incorrect error reporting at runtime. [ Low confidence ]
  • line 132: The protocolErrorsDictionary no longer includes the error code "0x7e273289" for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, 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 ]
  • line 132: The protocolErrorsDictionary no longer contains the previously supported error code key "0x7e273289" (an alternate selector for ERC721InvalidOwner). In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner. After the change to map[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 as ErrCodeNotInDic). 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 ]
  • line 132: Regression in protocolErrorsDictionary: the key "0x7e273289" that previously mapped to ERC721InvalidOwner(address owner) has been removed. The new dictionary includes only "0x89c62b64": ErrERC721InvalidOwner. If upstream code receives error selector 0x7e273289 (which was present in the prior version), lookups will now fail and likely fall back to ErrCodeNotInDic or equivalent handling, changing runtime behavior for a previously supported error code. [ Low confidence ]
  • line 132: The entry for the revert selector "0x7e273289" mapping to ERC721InvalidOwner(address owner) was present in the prior version but is missing from the updated protocolErrorsDictionary. Only "0x89c62b64": ErrERC721InvalidOwner remains. If upstream code encounters the 0x7e273289 selector (which the previous code recognized), lookups into protocolErrorsDictionary will 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 ]
  • line 132: The protocolErrorsDictionary type changed from map[string]string to map[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 of ErrCompileRegex), 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 ]
  • line 132: The updated protocolErrorsDictionary drops a previously supported error code "0x7e273289" for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" were mapped to the "invalid owner" condition. The new map includes only "0x89c62b64": ErrERC721InvalidOwner and 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 to ErrERC721InvalidOwner. [ Low confidence ]
  • line 132: Contract parity change: protocolErrorsDictionary changed type from map[string]string to map[string]error, and the values changed from human-readable messages (including parameter names) to pre-constructed error values 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. comparing error values, 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 ]
  • line 132: The protocolErrorsDictionary previously included a mapping for the error selector "0x7e273289" to ERC721InvalidOwner(...). In the updated code, this selector is no longer present in the map[string]error, leaving "0x7e273289" unmapped. Any runtime that encounters this selector will fail to resolve it via protocolErrorsDictionary and likely fall back to ErrCodeNotInDic, changing externally visible behavior for that error case. You should add "0x7e273289": ErrERC721InvalidOwner to restore parity with prior behavior. [ Low confidence ]
  • line 132: The type of protocolErrorsDictionary has changed from map[string]string to map[string]error (now mapping codes to pre-declared error values). 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 receive error and 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 ]
  • line 132: The mapping for the error selector "0x7e273289" (previously associated with ERC721InvalidOwner) has been removed from protocolErrorsDictionary. If this selector is still emitted by upstream protocols/contracts, lookups will fail and code will likely return ErrCodeNotInDic or an equivalent fallback, resulting in incorrect error classification at runtime. This is a contract-parity risk against previously supported inputs. [ Low confidence ]
  • line 132: The type of protocolErrorsDictionary changed from map[string]string to map[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 an error and 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 ]
  • line 132: The new protocolErrorsDictionary omits the previously supported error code "0x7e273289" for ERC721InvalidOwner(address). In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, 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 in ErrCodeNotInDic (or equivalent downstream handling), causing a behavioral regression and making a previously valid input path reach an error outcome. [ Low confidence ]
  • line 132: The mapping protocolErrorsDictionary no longer includes the revert code "0x7e273289" for ERC721InvalidOwner. In the previous version, both "0x89c62b64" and "0x7e273289" were mapped to ERC721InvalidOwner, 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 produce ErrCodeNotInDic or 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 ]
  • line 132: Contract parity regression: the mapping for error code "0x7e273289" (previously mapped to "ERC721InvalidOwner(address owner)") present in the prior version was removed in the new protocolErrorsDictionary. In the current code, only "0x89c62b64" maps to ErrERC721InvalidOwner. Any lookup that encounters revert code "0x7e273289" will now fail to resolve to a known error and will likely surface as ErrCodeNotInDic or equivalent in calling code, changing externally visible behavior and causing unrecognized errors at runtime. [ Low confidence ]
  • line 132: The protocolErrorsDictionary previously included a mapping for the error code "0x7e273289" to ERC721InvalidOwner(...) but this entry was removed in the new dictionary. If the upstream protocol still emits "0x7e273289", lookups into protocolErrorsDictionary will now fail, leading to a runtime path that likely returns ErrCodeNotInDic instead 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 ]
  • line 145: Regression: the protocolErrorsDictionary no longer includes the selector "0x7e273289" for ERC721InvalidOwner. In the previous version, both "0x89c62b64" and "0x7e273289" mapped to the ERC721InvalidOwner(...) signature, but the new map retains only "0x89c62b64". Any error decoding path that encounters on-chain error selector 0x7e273289 will 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 ]
  • line 145: Protocol error code "0x7e273289" for ERC721InvalidOwner(address owner) was present in the previous dictionary and is now missing from protocolErrorsDictionary. The new map includes only "0x89c62b64": ErrERC721InvalidOwner. Any revert matching selector 0x7e273289 will now be unmapped, causing lookups to fail (e.g., returning a generic ErrCodeNotInDic or equivalent in upstream logic), which is a runtime regression in error decoding. [ Low confidence ]
  • line 145: The protocolErrorsDictionary no longer includes the previously present selector key "0x7e273289" for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to "ERC721InvalidOwner(address owner)". After the change, only "0x89c62b64" maps to ErrERC721InvalidOwner, and the "0x7e273289" entry was removed. If upstream error messages contain the 0x7e273289 selector (e.g., from a different Solidity compiler or library version emitting the alternate signature ID), lookups in protocolErrorsDictionary will fail and fall through to ErrCodeNotInDic at runtime. This is a reachable runtime behavior change caused by the diff and breaks contract parity with the previous mapping set. [ Low confidence ]
  • line 145: The protocolErrorsDictionary no longer includes the selector "0x7e273289" for ERC721InvalidOwner. In the previous implementation, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner(address owner). After the change to map[string]error, only "0x89c62b64" remains. Any runtime path that receives the "0x7e273289" error code will not be recognized and will likely fall back to ErrCodeNotInDic, causing incorrect error handling for valid on-chain errors. [ Low confidence ]
  • line 145: protocolErrorsDictionary no longer contains an entry for the error selector "0x7e273289", which previously mapped to ERC721InvalidOwner. The current map only includes "0x89c62b64": ErrERC721InvalidOwner. Any code that encounters the selector 0x7e273289 will now fail to resolve to a known error and will likely fall back to a generic path (e.g., returning ErrCodeNotInDic), changing runtime behavior for that input. This is a functional regression from the prior dictionary which supported both selectors. [ Low confidence ]
  • line 145: The protocol errors dictionary previously included two distinct selector codes for ERC721InvalidOwner(...): "0x89c62b64" and "0x7e273289". In the updated protocolErrorsDictionary (now map[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 to ErrCodeNotInDic or equivalent, changing observable behavior for valid inputs. [ Low confidence ]
  • line 145: Regression in protocolErrorsDictionary coverage: the previous implementation included two distinct selectors for ERC721InvalidOwner(...): "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 see ErrCodeNotInDic or equivalent fallback instead of the expected error. This is a functional runtime bug because valid inputs (error code 0x7e273289) now terminate in an incorrect outcome (unmapped). [ Low confidence ]
  • line 145: The new protocolErrorsDictionary removed the alternate error code mapping for ERC721InvalidOwner. In the previous version, both "0x89c62b64" and "0x7e273289" were mapped to the ERC721InvalidOwner error (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 ]
  • line 145: The protocolErrorsDictionary no longer includes the selector "0x7e273289" for ERC721InvalidOwner, which previously existed in the old mapping. The current code only maps "0x89c62b64" to ErrERC721InvalidOwner. 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 ]
  • line 145: The mapping protocolErrorsDictionary no longer contains the previously-present key "0x7e273289" for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, but the new map only includes "0x89c62b64". Any runtime path that parses an error code of 0x7e273289 will 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 ]
  • line 145: The updated protocolErrorsDictionary no longer includes the code "0x7e273289" for ERC721InvalidOwner. In the previous version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, 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 to ErrCodeNotInDic, creating a runtime mismatch for valid protocol errors. Add a mapping for "0x7e273289" to ErrERC721InvalidOwner to preserve behavior and handle all known variants. [ Low confidence ]
  • line 145: The updated protocolErrorsDictionary mapping omits the previously supported error code "0x7e273289" for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, whereas the new map only includes "0x89c62b64": ErrERC721InvalidOwner. If upstream inputs include "0x7e273289" (which was formerly recognized), lookups will fail and will likely resolve to ErrCodeNotInDic, 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 ]
  • line 145: The previous mapping included a distinct protocol error hash "0x7e273289" for ERC721InvalidOwner(address owner), which is missing in the new protocolErrorsDictionary. 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 as ErrCodeNotInDic or otherwise unrecognized, resulting in incorrect error handling at runtime. [ Low confidence ]
  • line 145: The protocolErrorsDictionary lost support for the error code selector "0x7e273289" that previously mapped to ERC721InvalidOwner. 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 to ErrERC721InvalidOwner). Any upstream logic that decodes revert data containing the "0x7e273289" selector will now fail to find it in the dictionary and likely return ErrCodeNotInDic or equivalent fallback, causing incorrect runtime behavior for valid inputs that used to be handled. You should re-add "0x7e273289": ErrERC721InvalidOwner to protocolErrorsDictionary. [ Low confidence ]
  • line 145: The protocolErrorsDictionary no longer includes the alternate selector "0x7e273289" for the ERC721InvalidOwner error (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 to ErrCodeNotInDic (or equivalent), causing incorrect runtime behavior. Add "0x7e273289": ErrERC721InvalidOwner to preserve support for both selectors. [ Low confidence ]
  • line 145: The protocolErrorsDictionary previously contained a mapping for the selector "0x7e273289" to an ERC721 invalid owner error string. In the new code, only "0x89c62b64": ErrERC721InvalidOwner remains and the "0x7e273289" mapping has been removed entirely. If upstream logic encounters the 0x7e273289 error selector (which was present before), looking it up in protocolErrorsDictionary will now fail and likely produce ErrCodeNotInDic or 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 ]
  • line 145: The protocolErrorsDictionary no longer includes the previously mapped error code "0x7e273289" for ERC721InvalidOwner. In the old version, both "0x89c62b64" and "0x7e273289" were mapped to ERC721InvalidOwner, but the new map only includes "0x89c62b64". If the protocol emits "0x7e273289", lookups will now fail (likely resulting in ErrCodeNotInDic downstream), breaking contract parity with prior behavior. Add the missing "0x7e273289" mapping to preserve coverage for all known protocol error codes. [ Low confidence ]
  • line 145: The new protocolErrorsDictionary omits a selector that previously mapped to ERC721InvalidOwner. In the prior version there were two distinct selectors for ERC721InvalidOwner: "0x89c62b64" and "0x7e273289". In the updated code, only "0x89c62b64" is present. Any runtime lookup for error code "0x7e273289" will now fail (likely resulting in ErrCodeNotInDic downstream) even though it was handled before. This is a regression in error-code coverage. [ Low confidence ]
  • line 145: The updated protocolErrorsDictionary omits the previously present mapping for the selector "0x7e273289" (an alternate selector for ERC721InvalidOwner). In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner. After the change, only "0x89c62b64" is present. If upstream emits "0x7e273289", a lookup will now return the zero value (a nil error), 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 ]
  • line 145: The updated protocolErrorsDictionary omits the selector "0x7e273289" for ERC721InvalidOwner. In the previous version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner. 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 ]
  • line 145: Previously, the protocol errors dictionary included a mapping for the error code "0x7e273289" to the ERC721 invalid owner error. In the updated protocolErrorsDictionary (now map[string]error), the mapping for "0x7e273289" has been removed, and only "0x89c62b64": ErrERC721InvalidOwner remains. If upstream errors contain the code 0x7e273289, tryExtractProtocolError will now return ErrCodeNotInDic instead of the appropriate ErrERC721InvalidOwner error. This is a runtime behavior regression/compatibility bug that can cause valid protocol errors to be misclassified as unknown. [ Low confidence ]
  • line 145: The protocolErrorsDictionary no longer includes the key "0x7e273289" for the ERC721InvalidOwner error, 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 in ErrCodeNotInDic behavior upstream. To fix, restore the missing mapping: "0x7e273289": ErrERC721InvalidOwner. [ Low confidence ]
  • line 145: The new protocolErrorsDictionary (type map[string]error) omits a previously present mapping for the error selector "0x7e273289", which was an alias for ERC721InvalidOwner(address owner). In the prior code, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner. 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 as ErrCodeNotInDic (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 ]
  • line 145: The mapping of protocol error codes in protocolErrorsDictionary removed a previously supported selector for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to the ERC721InvalidOwner error. 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 return ErrCodeNotInDic or an equivalent fallback. This is a runtime behavioral regression and breaks contract parity for previously handled inputs. [ Low confidence ]
  • line 145: The new protocolErrorsDictionary omits a previously supported error code "0x7e273289" for ERC721InvalidOwner. In the prior mapping (pre-diff), both "0x89c62b64" and "0x7e273289" were present and mapped to ERC721InvalidOwner(address owner). After the change, only "0x89c62b64" is mapped to ErrERC721InvalidOwner, 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., returning ErrCodeNotInDic or 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 ]
  • line 145: Missing protocol error code mapping: the previous implementation included two distinct selectors for ERC721InvalidOwner, specifically "0x89c62b64" and "0x7e273289". In the updated protocolErrorsDictionary (now map[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 ]
  • line 145: protocolErrorsDictionary previously contained two distinct codes for ERC721InvalidOwner ("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 to ErrCodeNotInDic, causing incorrect error handling at runtime. This is a regression in the dictionary coverage and can lead to misclassification of errors. [ Low confidence ]
  • line 145: The protocolErrorsDictionary map omits the previously supported selector "0x7e273289" for ERC721InvalidOwner(address), which was present before the change. Now only "0x89c62b64": ErrERC721InvalidOwner is included. If the protocol can emit either of these selectors, lookups for "0x7e273289" will fail and any code relying on this dictionary may return ErrCodeNotInDic or otherwise mis-handle the error, causing a runtime behavior regression for those inputs. [ Low confidence ]
  • line 145: Previously, protocolErrorsDictionary included two distinct selector keys for ERC721InvalidOwner: "0x89c62b64" and "0x7e273289". In the new code, only "0x89c62b64": ErrERC721InvalidOwner remains, and the mapping for "0x7e273289" has been removed. If upstream contracts can still emit the 0x7e273289 selector, lookups into protocolErrorsDictionary will now fail, likely resulting in ErrCodeNotInDic or equivalent fallback paths at runtime. This is a behavior regression and can cause previously handled errors to become unrecognized. [ Low confidence ]
  • line 145: The protocolErrorsDictionary omits the known selector "0x7e273289" for ERC721InvalidOwner that existed prior to the change. In the previous implementation, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner(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., returning ErrCodeNotInDic). 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 ]
  • line 145: The mapping for ERC721InvalidOwner previously included two different error selectors ("0x89c62b64" and "0x7e273289") for the same Solidity error signature, but in the updated protocolErrorsDictionary only "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 ]
  • line 145: The updated protocolErrorsDictionary omits the previously present key "0x7e273289" that mapped to ERC721InvalidOwner(...). In the prior implementation, both "0x89c62b64" and "0x7e273289" were recognized as variants of ERC721InvalidOwner. The new dictionary only includes "0x89c62b64": ErrERC721InvalidOwner and 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 to ErrCodeNotInDic or another generic path, causing a behavior regression. This is a concrete, externally visible runtime behavior change introduced by the diff. [ Low confidence ]
  • line 145: Previously, protocolErrorsDictionary included two distinct selector keys for ERC721InvalidOwner: "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 in protocolErrorsDictionary will fail, causing a "code not found" behavior (e.g., returning ErrCodeNotInDic) 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 ]
  • line 145: The protocolErrorsDictionary mapping dropped support for the ERC721 InvalidOwner error selector "0x7e273289" that was present before the diff. In the old mapping there were two selectors for ERC721InvalidOwner(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 to ErrERC721InvalidOwner. This is a behavioral/runtime compatibility issue, not a compilation error. [ Low confidence ]
  • line 145: The updated protocolErrorsDictionary no longer includes the alternative selector key "0x7e273289" that previously mapped to ERC721InvalidOwner(address owner). Only "0x89c62b64": ErrERC721InvalidOwner remains. If any upstream contracts emit the ERC721InvalidOwner error with the removed selector, lookups will now fail at runtime (e.g., yielding a "not found" outcome via ErrCodeNotInDic in callers). This is an externally visible behavior change that can cause valid revert codes to be silently unmapped and mishandled. [ Low confidence ]
  • line 145: The protocolErrorsDictionary lost a previously supported selector key for the same ERC721InvalidOwner error. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner(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 as ErrCodeNotInDic. 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 ]
  • line 145: The mapping for the ERC-721 InvalidOwner error is missing the previously present error code key "0x7e273289". Only "0x89c62b64" is mapped to ErrERC721InvalidOwner. If on-chain revert data uses 0x7e273289, lookup into protocolErrorsDictionary will fail and likely result in ErrCodeNotInDic downstream, causing incorrect error handling for a valid protocol error. [ Low confidence ]
  • line 145: The protocolErrorsDictionary mapping no longer includes the previously present key "0x7e273289" for the ERC721InvalidOwner error. The prior version mapped both "0x89c62b64" and "0x7e273289" to ERC721InvalidOwner(...). After the change, only "0x89c62b64" is mapped (to ErrERC721InvalidOwner). If the blockchain emits the error code "0x7e273289", lookups against protocolErrorsDictionary will fail and callers relying on a successful mapping will experience a runtime error condition (e.g., returning ErrCodeNotInDic or 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 ]
  • line 145: The mapping protocolErrorsDictionary no longer includes the selector "0x7e273289" for ERC721InvalidOwner(address owner), which existed before the change. Now only "0x89c62b64": ErrERC721InvalidOwner is present. If upstream code encounters on-chain errors with selector 0x7e273289, lookups will fail and likely surface ErrCodeNotInDic at runtime instead of the intended mapped error. [ Low confidence ]
  • line 145: Regression: the protocolErrorsDictionary no longer includes the previously supported error code "0x7e273289" for ERC721InvalidOwner. In the prior version, both "0x89c62b64" and "0x7e273289" mapped to the ERC721 invalid owner error signature. In the updated code, only "0x89c62b64" remains (mapping to ErrERC721InvalidOwner at protocolErrorsDictionary["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 ]
  • line 145: The new protocolErrorsDictionary removed a previously supported error code mapping for ERC721InvalidOwner. In the original map there was an entry for "0x7e273289" (also mapped to ERC721InvalidOwner(address owner)), but in the updated map only "0x89c62b64": ErrERC721InvalidOwner remains. If upstream inputs can still emit the 0x7e273289 code, lookups will now fail and downstream logic may incorrectly treat the error as unknown (e.g., returning ErrCodeNotInDic). This is a runtime behavior regression caused by the diff, not a compile-time issue. [ Low confidence ]
  • line 145: The updated protocolErrorsDictionary removes the previously present mapping for the error code "0x7e273289" which also represented ERC721InvalidOwner. The old dictionary had two distinct selectors for ERC721InvalidOwner ("0x89c62b64" and "0x7e273289"). The new dictionary only includes "0x89c62b64": ErrERC721InvalidOwner and omits "0x7e273289". If upstream inputs contain the missing selector, lookups will fail (e.g., returning a default or causing fallback to ErrCodeNotInDic), resulting in incorrect error normalization at runtime. To fix, reintroduce the "0x7e273289" key pointing to ErrERC721InvalidOwner. [ Low confidence ]
  • line 145: The new protocolErrorsDictionary omits the selector "0x7e273289" that previously mapped to ERC721InvalidOwner(...). 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 into protocolErrorsDictionary will 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 ]
  • line 145: The updated protocolErrorsDictionary removed support for the error selector "0x7e273289" which previously mapped to "ERC721InvalidOwner(address owner)". In the new map, only "0x89c62b64" is mapped to ErrERC721InvalidOwner. If contracts can emit both selectors, inputs containing "0x7e273289" will now fail lookup and likely fall back to ErrCodeNotInDic, causing incorrect behavior. Add "0x7e273289": ErrERC721InvalidOwner to preserve parity with the prior behavior. [ Low confidence ]
  • line 145: The protocolErrorsDictionary no longer includes the selector "0x7e273289" for ERC721InvalidOwner. In the previous version, both "0x89c62b64" and "0x7e273289" mapped to ERC721InvalidOwner, 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 ]
  • line 145: The entry for the error code "0x7e273289" (a variant of ERC721InvalidOwner) that existed in the previous protocolErrorsDictionary has been removed in the new mapping. The old dictionary had two codes for ERC721InvalidOwner ("0x89c62b64" and "0x7e273289"), but the new map[string]error only includes "0x89c62b64". Any runtime lookup for "0x7e273289" will now fail to resolve to the intended error and will likely result in a fallback such as ErrCodeNotInDic. This reduces coverage and can misclassify on-chain error decodes for valid inputs. [ Low confidence ]
  • line 146: The protocolErrorsDictionary previously included two selectors for ERC721InvalidOwner, including "0x7e273289", but the new map only includes "0x89c62b64" and drops "0x7e273289". If on-chain errors are emitted using the 0x7e273289 selector, lookups into protocolErrorsDictionary will fail, likely leading to ErrCodeNotInDic being returned downstream. This is a functional regression and a runtime bug whenever that selector appears in inputs. [ Low confidence ]

@fbac fbac requested a review from a team as a code owner October 9, 2025 15:36
@graphite-app
Copy link

graphite-app bot commented Oct 9, 2025

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • Queue - adds this PR to the back of the merge queue
  • Hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

"0xa9fbf51f": ErrERC721InvalidApprover,
"0x5b08ba18": ErrERC721InvalidOperator,
"0x89c62b64": ErrERC721InvalidOwner,
"0x64a0ae92": ErrERC721InvalidReceiver,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A valid protocol error selector 0x7e273289 was inadvertently removed from protocolErrorsDictionary, causing tryExtractProtocolError to return ErrCodeNotInDic instead of decoding upstream ERC721InvalidOwner errors. Re-add the mapping "0x7e273289": ErrERC721InvalidOwner to protocolErrorsDictionary so that both known selectors correctly resolve to ErrERC721InvalidOwner.

+    "0x7e273289": ErrERC721InvalidOwner,

🚀 Reply to ask Macroscope to explain or update this suggestion.

👍 Helpful? React to give us feedback.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cast sig "ERC721InvalidOwner(address)" returns 0x89c62b64

@fbac fbac merged commit 4fd0c57 into main Oct 9, 2025
11 checks passed
@fbac fbac deleted the 10-09-typed_blockchain_errors branch October 9, 2025 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants