This repository has been archived by the owner on Feb 26, 2024. It is now read-only.
Put try/catch guard around ENS forward resolution in decoder/debugger #6083
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.
PR description
This PR fixes an issue noticed by @gnidan. Turns out that ENSJS will throw an error if you try to resolve an ENS name which contains certain characters not permitted in URLs[0], such as 🪴 (but apparently 🍑 is fine). This despite the fact that it has no problem with them on reverse resolution, and apparently it was possible to register these names in the first place (presumably by just not using ENSJS).
Since I don't really want to go tearing out ENSJS right now, I'm fixing this the crudest way possible, with a blunt try/catch. I could check for the particular error message, but that's probably too brittle.
(Notionally I could use a library (ideally one we're already implicitly using) to check for the particular illegal characters, but that seems a bit too much work for something like this.)
[0] I'm a little unclear at this point, honestly. Suffice it to say that there is apparently at least one convention under which they are illegal, and ENSJS is applying this convention.
Testing instructions
Nick found this issue by attempting to use the decoder to decode the state variables (as of block
17445497
) of the mainnet contract at address0xa39739ef8b0231dbfa0dcda07d7e29faabcf4bb2
, having obtained its source via fetch-and-compile. The particular variable that causes the error is called "TroveOwners". Try executing the following commands innode --experimental-repl-await
: (or run this outside the repl I guess :P )That last line should not error. (Without this fix, it does.)