Adding Records and Resolvers Exhibits Inconsistent Behavior about ens-app

[michaelelliot]

Multicall.js may be able to solve this for you (in a general purpose way), because it returns the block number along with the aggregated results from multiple calls.

[makoto]

@chris-remus fixed the bug and deployed again. There is still a few sec time lag but should rerender on its own. https://imaginary-summer.surge.sh

[jefflau]

Closing this. Reopen if still an issue

[Arachnid]

I just noticed this with setting a resolver on Goerli.

[jefflau]

@Arachnid What exact behaviour did you see nick? Can you give instructions for replication?

@makoto Can you take a look at this?

[Arachnid]

I set a resolver for the first time. It shows the 'tx pending' spinner, then after a while that goes away and the page reloads, but still shows 0x0... as the resolver address. A few seconds later, Metamask reports the transaction as mined, and I have to manually reload the page to see the new resolver.

[jefflau]

That sounds a little bit different than the bug Chris reported. Can you reproduce the bug on Ropsten? I was having a lot of issues with Goerli not giving me the txReceipt event from web3, which is why I asked you to deploy on ropsten

[Arachnid]

1 - After Tx confirmation, resolver doesn't appear set unless page is refreshed, sometimes it doesn't appear at all.

I think this is the same bug as Chris reported.

I can't seem to reproduce it on Ropsten. Goerli is definitely reloading, though - it just seems to happy too early.

[Arachnid]

In a conversation with @michaelelliot we just realised the probable cause of this: The calls to update the UI after the transaction is mined are going to a node that's a block behind, and so aren't reflecting the new state.

[jefflau]

That makes sense. Especially since Goerli confirms so quickly. Is there something we can do?