-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Background info
@0xthrpw reached out to report the following:
query getMetadata {
domains(where: {name: "encrypteddegen.eth"}) {
name
resolver {
address
texts
textChangeds {
key
value
}
addr {
id
}
multicoinAddrChangeds {
addr
id
coinType
transactionID
}
contentHash
contenthashChangeds {
hash
}
}
}
}
The above query returns null values for textChangeds.
He reported the same issue when querying for the name "nick.eth".
Both "nick.eth" and "encrypteddegen.eth" are using 0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41 as their resolver.
We have an important note documented about this resolver here:
ensnode/packages/datasources/src/mainnet.ts
Lines 363 to 369 in 4cf6f41
| // aka 'LegacyPublicResolver' in the ENS Subgraph terminology | |
| // this resolver uses a TextChanged event that does not include the `value` parameter | |
| DefaultPublicResolver3: { | |
| abi: ResolverABI, | |
| address: "0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41", | |
| startBlock: 9412610, | |
| }, |
Specifically: "this resolver uses a TextChanged event that does not include the value parameter".
You can see this issue by looking at how the TextChanged event is defined here: https://etherscan.io/address/0x4976fb03c32e5b8cfe2b6ccb31c09ba78ebaba41#code
Proposed solution
I believe we should be able to solve for this using a similar strategy as we implemented to solve #859.
Specifically: even though the TextChanged event from this contract does not include the value param, whenever we index this event we can make an RPC call (scoped to the same block number as is currently being indexed) to get the value of that resolver record as of the associated block number.
This will add more RPC calls that slows down the backfill process, which is unfortunate, but let's optimize for maximum value for integrators querying data from ENSNode.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status