Metamask-extension: Genesis block hash incorrect in 3.7.2 after switching networks

[nanexcool]

If I access a dapp in mainnet, then switch to kovan, querying for block 0 data is wrong. This is happening when switching networks...

For example, I was in kovan then switched to mainnet.

web3.eth.getBlock(0,(e,r) => console.log(r.hash))
0x1f937ead8fa6c3be7fe23e020174bc9d98c63de0240463e2510363993b849c77

Different than https://etherscan.io/block/0

Querying for block 1 works. Looks like a weird caching issue?

Testing using https://oasisdex.com/ (I'm one of the devs) and we use the genesis block hash to determine network.

[livnev]

I'm experiencing the same issue.

[peculiarity]

Querying for block 1 and using parentHash only work once. i.e I'm on mainnet and switch to kovan , the parentHash value in the first block is something completely different from the hash value that should be ( hash value of block 0 )

[danfinlay]

Sorry for the issue, this is great validation of our decision to only roll out to 10% of our users "just in case".

This will be a top priority today. Unfortunately, on my initial attempt, I failed to reproduce the problem.

To the people who have experienced this:

1. When you switch provider, does the page reload? 3.7.2 should be reloading pages that have used web3 when you change provider.
2. Have you tried entirely resetting the browser? I'm imagining some chrome bug where you may have gotten a partial update? Probably unlikely.

I'll have more members of the team try to reproduce so we can track this down sooner. Any other clues could be helpful.

[livnev]

@flyswatter 1. Yes, switching the network/node does now cause the page to reload.

1. Haven't tried a browser reset yet, will report back.

[danfinlay]

Also, for people experiencing this problem, are you also getting wrong results when calling web3.version.getNetwork(console.log)?

[kumavis]

mainnet https://etherscan.io/block/0 -> 0xd4e567...
kovan https://kovan.etherscan.io/block/0 -> 0xa3c565...
ropsten https://ropsten.etherscan.io/block/0 -> 0x419410...

checking block hash in console via:

web3.eth.getBlock(0, (err, block) => console.log(block.hash))

seems to be behaving correctly to me on master (3.7.2)

[danfinlay]

Okay so @Zanibas was finally able to reproduce this from the store build, it looks like master may be fixed, so we may just need to version bump & republish this.

[nanexcool]

@flyswatter getNetwork is working properly for me

[danfinlay]

Okay so since we were able to reproduce with 3.7.2 but not on master, we're re-building and publishing it as 3.7.3, please let us know if that version fixes the behavior.

[livnev]

3.7.3 is in the chrome web store but I am still experiencing the same problem:

web3.eth.getBlock(0, (err, block) => console.log(block.hash))

returns 0x34d13ac20ffa6209f9444f1184dfaaa6b375d5ece42765c507f220610338e3d7 instead of 0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3

[danfinlay]

Really! So you're on 3.7.3, too?

[livnev]

@flyswatter Yes, updated through chrome, restarted chrome, restarted extension, etc.

[danfinlay]

This is very weird. I'm locally loading the exact bundle that we published, and I'm unable to reproduce, but everyone with a published version seems to experience this. Trying to figure out what can change in that period.

[danfinlay]

I have 3.7.3 installed from the store, and am failing to reproduce. I need another @MetaMask/devs trying to trace this.

[nanexcool]

@flyswatter 3.7.3 just installed from store. Having same issue still, followed same steps as @livnev

[danfinlay]

Could someone experiencing this issue try reproducing with their background console open? Look for any red error text? https://github.com/MetaMask/faq/blob/master/LOGS.md#background-logs-chrome

[livnev]

@flyswatter Nothing in there seems to be related. The only thing I have is a bunch of:

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.

[peculiarity]

@flyswatter I have to go with @nanexcool . Still nothing resolved.

[danfinlay]

I understand that, thanks @peculiarity. I believe everyone here that this is an issue, I'm looking for causes at this point, because I'm not experiencing the problem myself.

[danfinlay]

Are all three of you: @nanexcool, @livnev, @peculiarity, all experiencing this on Oasisdex? Is it possible Oasisdex is doing some caching? Are you using ProviderEngine in your stack?

I was able to reproduce on Oasisdex, my first reproduction. I got a bad block 0 hash on main-net, but switching to ropsten, I got the correct block 0 hash.

In fact, every time I switch to main-net, I seem to get a different block 0 hash back.

This should be enough for me to track down, anyway.

[peculiarity]

@flyswatter I don't have to be on oasisdex page.
Currently I have tab opened google.com.
web3.eth.getBlock(0,(err,res) => {console.log(res.hash)})

the output is:

0x1ea0fdca29cf4c4319d8f2a414440a96636002838b423236cdeefe9995f7cac7

Note: I'm on Kovan

[danfinlay]

Okay I've made a good breakthrough that should allow a proper fix.

The returned wrong hash is actually the hash of a recent block, as it was returned by getBlockByNumber('latest') the first time MetaMask calls it when initializing its provider. Looks like for some reason getBlock('0') has the same cache identifier as getBlock('latest').

This looks like it was probably introduced by a change made to our cacheIdentifierForPayload method, which I now notice does not account for block tag.