Oraclise not able to detect the network when using OpenZeppelin Test Environment

@shark0der on Telegram asked:

Hey there! Did anyone else ran into the oraclise not being able to detect the network when using oz test env?

It seems that ethereum-bridge solves this because it has a hardcoded key which it uses to deploy the contract at a predefined address, however I’m not sure why this worked out of the box in the truffle project

I’ve actually took another path and avoided the use of oraclize altogether, but this seems to be a problem nevertheless. I’ll illustrate the idea and maybe a discussion can be started in this direction for other people that might run into this issue. I won’t share the contract code for now because there are too many details and it’s out of scope for this conversation.

I have a contract that inherits usingOraclize.sol. When calling oraclize_query from the base contract, the usingOraclize checks the network it’s on by using getCodeSize on a number of predefined addresses (OraclizeAddrResolver) that are already deployed on different networks and if the code size is != 0 it considers that it is on that network.

For private networks, this works by using the ethereum-bridge npm package. One should start it in command-line and connect to an existing ganache instance and it deploys all the needed contracts. Given the fact that test environment spins up a ganache instance behind the courtains and the users don’t have control over the port it uses, this scenario is not doable. One possible workaround would be to start ganache manually, then start ethereum bridge and point it to the ganache port and then configure oz to fork the ganache network. This seems a bit too much and not ideal but I think it might work. Might also fail and require restarts from time to time. Will be slightly more complicated to setup in CI environments as well.

A clean way to implement this I believe should be an oz plugin that would do all this magic behind the scenes and offer the user everything ready. The shitty part is that I don’t see any documentation on the programatic access for ethereum-bridge and it’s also rarely updated.

What puzzles me more than anything is that when I was using truffle, it worked out of the box (sending oraclize queries, don’t know about receiving), even though I didn’t have ethereum-bridge (checked with npm ls ethereum-bridge). Maybe someone knows more details about this.

As stated before, I gave up on the oraclize usage and took another path so I’ll leave this open for discussion for other people that might encounter this problem.