VM is initially undefined on provider object

[cgewecke]

Something about the VM creation is asynchronous & ganache isn't waiting for it.

Reproduction

const ganache = require('ganache-core');

const provider = ganache.provider();
let counter = 0;

console.log(`Initial VM value: ${provider.engine.manager.state.blockchain.vm}`);

const interval = setInterval(() => {
  if (provider.engine.manager.state.blockchain.vm !== undefined){
    console.log(`Final VM value: ${provider.engine.manager.state.blockchain.vm}`)
    clearInterval(interval);
  } else {
    counter++;
    console.log(`VM undefined @tick ${counter}`)
  }
});

Output

Initial VM value: undefined
VM undefined @tick 1
VM undefined @tick 2
Final VM value: [object Object]

Expected Behavior

That the provider instantiation call is synchronous - there's no need to wait for its subcomponents to resolve before referencing them.

Context

I'd like to attach to the VM and listen to its step. Additionally, there are API extensions in development at ethereumjs-vm I'd like to take advantage of in future.

There's a trivial workaround - just opening here in case other people run into this unexpectedly as well.

Your Environment

• Version used: v2.6.0
• Operating System and version: OSX

cf: solidity-coverage 0.7.0

[davidmurdoch]

The vm creation will (likely) always be done asynchronously, as it relies on disk IO in some cases.

Also, you are 5 levels into undocumented internals here; I wouldn't rely on any of these properties existing in the future.

Would #381 solve your issue? Or would you prefer the Ganache provider just emit low-level events like the vm's step itself (e.g., provider.on("vm:step", handler))?

[cgewecke]

Thanks @davidmurdoch

The vm creation will (likely) always be done asynchronously, as it relies on disk IO in some cases.

Isn't this a little worrying / race-condition-y? Who is doing the disk I/O? Can't they do it sync?

you are 5 levels into undocumented internals here

Yes, ideally I would like provider.vm and be able consume whatever API ethereumjs-vm is developing directly.

cf: 0xProject monorepo 1891

[davidmurdoch]

Isn't this a little worrying / race-condition-y? Who is doing the disk I/O? Can't they do it sync?

No race condition here, as we queue all RPC calls until the entire node has initialized. There are a few async init tasks done in parallel, so changing to sync may have an adverse effect on start up performance. In any case, we'd have to patch or fork some libraries to make them work synchronously.

I would like provider.vm

Exposing a third party library as part of our official API would tie us to a release based on their own semver changes, which I'd rather not do. I'd much rather abstract these things away so we can handle these breaking changes in a backwards-compatible way when they occur.

[cgewecke]

No race condition here, as we queue all RPC calls until the entire node has initialized.

Ah ok cool! Thanks for that, good to know.

Exposing a third party library as part of our official API would tie us to a release based on their own semver changes,

Yes this makes sense. Could you expose it informally, with the documented caveat that consumers should be aware that they are responsible for tracking & managing API changes upstream? The number of engineers interested in tapping the VM directly is small & 'vm-aware'. They might be happy to trade convenient access for semver guarantees.

TBH I'd prefer direct exposure just because it means I don't have to litigate or wait for changes to the abstraction here :) Conversely, if it's something you're interested in taking on as a first order concern then awesome - it seems like there's a lot of cool stuff being added to the VM atm.

I'm going to close since the core issue is resolved. Thanks again @davidmurdoch!

[cgewecke]

Oh, maybe a provider.on('ready', handler) ?