getCode() not returning bytecode; "Request-Rate Exceeded" notice on hardhat test running on localhost

[grapevinegizmos]

Ethers Version

8.5.0

Search Terms

No response

Describe the Problem

Running this test on hardhat

        let bcoll1 = await bindingColl_fact.deploy(account0.address, root.address);
        let bcoll = await bcoll1.deployed();
        expect(await bcoll.BKVersion()).eq("V0.1.10");  //test [asses
        let provider = ethers.getDefaultProvider();
        let code = await provider.getCode(bcoll.address);
        console.log(code);

produced this warning but completed successfully

========= NOTICE =========
Request-Rate Exceeded  (this message will not be repeated)

The default API keys for each service are provided as a highly-throttled,
community resource for low-traffic projects and early prototyping.

While your application will continue to function, we highly recommended
signing up for your own API keys to improve performance, increase your
request rate/limit and enable other perks, such as metrics and advanced APIs.

For more details: https://docs.ethers.io/api-keys/
==========================

which seems weird because the test is running on the local hardhat node.

It also returns only '0x' to the getCode request in penultimate line of test. It doesnt seem like these two errors are related but I"m unsure. The bytecode is big.

Code Snippet

No response

Contract ABI

No response

Errors

No response

Environment

No response

Environment (Other)

No response

[ricmoo]

This line will connect to a default set of providers, backed by INFURA, Alchemy, etc. which is why you are getting that warning, as you are not providing your own API keys and using the community-provided resources by those services:

let provider = ethers.getDefaultProvider();

[grapevinegizmos]

I understand about the default set of providers, normally i use an alchemy provider But in this case, the the chain I'm connected to is the local hardhat chain running on my local machine, so I am thinking that I don't need to connect to some external provider thus I'm not consuming any scarce resources except my own. Sorry wrong npm command, ethers is 5.6.2

[ricmoo]

But your code isn’t connecting to hardhat. It’s connecting to INFURA, et al. via the default provider call. Unless hardhat is hijacking the getDefaultProvider function.

[grapevinegizmos]

As I mentioned, I'm running this inside a hardhat test, which runs on a locally hosted hardhat node that only exists for the duration of the st and is then recreated. If you run address0.provider.getNetwork() the result is `{chainId: 31337, name 'unknown'}. Trying to provide some guidance in getDefaultProvider such as getDefaultProvider('localhost') or 'hardhat' or 'unknown' or 31337 noneof it works, which makes it hard to construct any test which uses getDefaultProvider -- or rather the provider on which the test construct is known for the duration of the test. So how can you run provider.getCode(some address) is theproblem I can't seem to solve.

[ricmoo]

I don’t know hardhat or how you get a provider in it, but I don’t think getDefaultProvider is the function you want.

There should be a hardhat-specific way to get the hardhat provider.

The getDefaultProvider is an ethers function and should have nothing to do with hardhat.

They probably provide some example code somewhere on how to get access to hardhat’s provider?

[zemse]

As I mentioned, I'm running this inside a hardhat test, which runs on a locally hosted hardhat node

You should use hre.ethers.provider to get a ethers provider (which extends the type ethers.providers.Provider).

[grapevinegizmos]

I don’t want to use the HRE because ultimately I want to deploy this to Google Cloud functions. I’d like to figure out how to do this with ‘unextended’ ethers.js From: soham ***@***.***> Reply-To: "ethers-io/ethers.js" ***@***.***> Date: Thursday, April 28, 2022 at 6:25 AM To: "ethers-io/ethers.js" ***@***.***> Cc: Josh Kramer ***@***.***>, Author ***@***.***> Subject: Re: [ethers-io/ethers.js] getCode() not returning bytecode; "Request-Rate Exceeded" notice on hardhat test running on localhost (Discussion #2932) As I mentioned, I'm running this inside a hardhat test, which runs on a locally hosted hardhat node You should use hre.ethers.provider to get a ethers provider (which extends the type ethers.providers.Provider). — Reply to this email directly, view it on GitHub<#2932 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACCIEBLWQUCSTPCCXDWSM23VHKGT3ANCNFSM5UNHYCJQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[zemse]

I don’t want to use the HRE because ultimately I want to deploy this to Google Cloud functions. I’d like to figure out how to do this with ‘unextended’ ethers.js

On which network do you intend to deploy? Since getCode doesn't return the byte code, I think the provider's network is likely incorrect. Posting these links incase you find these useful to help yourself:

• docs for getDefaultProvider
• list of supported networks
• JsonRpcProvider if you want to connect to a private network

If you find that network is actually correct, can you provide more information about your setup?

[grapevinegizmos]

Thanks. I see that when you a run a hardhat test without the network flag (which means its running on a hardhat-created node on the localmachine), getDefaultProvider().network return "homestead". I had thought it would return the local hardhat created network node provider. I don't see a mechanism to get a handle on hardhat's local testing provider, but I will keep searching.

[grapevinegizmos]

I was able to solve (finally), but getting the hardhat provider from one of the signers returns by await ethers.getSigners();
i.e.

   [signer] = await ethers.getSigners();
   provider = signer.provider;
   let code = provider.getCode(contractAddress);

Seems like a kind of hacky way to do it but it work. It would make more sense to me at least if "getDefaultProvider()" returned the network actually connected to, instead of Ethereum mainnet, but this works for now, so that's good.

[ricmoo]

Yes, hardhat has nothing to do with ethers, but they attach some functions to the ethers namespace. ethers.getSigner is part of Hardhat and has nothing to do with ethers. I’m surprised they won’t offer a function to get their provider… Have you checked on their GitHub issues?

[zemse]

In hardhat, they just add a provider prop to the ethers namespace: so you can use ethers.provider (or hre.ethers.provider). I didn't find that in the docs, once even I was using the signer.provider thing as you have figured, then thought there should be a better way and asked in their discord.

[grapevinegizmos]

Yeah, I've been getting that sort of message from both you folks and hardhat (Nothing to do with hardhat, try ethers).

It's quite confusing for newbieish: For example, if I want to get a handle on the abi for a simple contract like this:

pragma solidity 0.8.6;
contract FireTest {
    string public name;
    uint8 public age;
    constructor(string memory _name, uint8 _age) {
        name = _name;
        age = _age;
    }
}

If I attempt to get the abi in hardhat from the artifacts hardhat creates as follows:

   import FireTestJson from '../artifacts/contracts/FireTest.sol/FireTest.json'
   let HHABI = FireTestJson.abi;
   console.log(HHABI)

That yields:

[
  {
    inputs: [ [Object], [Object] ],
    stateMutability: 'nonpayable',
    type: 'constructor'
  },
  {
    inputs: [],
    name: 'age',
    outputs: [ [Object] ],
    stateMutability: 'view',
    type: 'function'
  },
  {
    inputs: [],
    name: 'name',
    outputs: [ [Object] ],
    stateMutability: 'view',
    type: 'function'
  }
]

But if I try to get the ABI directly from the contract using ethers (using contract.interface I get:

Interface {
  fragments: [
    ConstructorFragment {
      name: null,
      type: 'constructor',
      inputs: [Array],
      payable: false,
      stateMutability: 'nonpayable',
      gas: null,
      _isFragment: true
    },
    FunctionFragment {
      type: 'function',
      name: 'age',
      constant: true,
      inputs: [],
      outputs: [Array],
      payable: false,
      stateMutability: 'view',
      gas: null,
      _isFragment: true
    },
    FunctionFragment {
      type: 'function',
      name: 'name',
      constant: true,
      inputs: [],
      outputs: [Array],
      payable: false,
      stateMutability: 'view',
      gas: null,
      _isFragment: true
    }
  ],
  _abiCoder: AbiCoder { coerceFunc: null },
  functions: {
    'age()': FunctionFragment {
      type: 'function',
      name: 'age',
      constant: true,
      inputs: [],
      outputs: [Array],
      payable: false,
      stateMutability: 'view',
      gas: null,
      _isFragment: true
    },
    'name()': FunctionFragment {
      type: 'function',
      name: 'name',
      constant: true,
      inputs: [],
      outputs: [Array],
      payable: false,
      stateMutability: 'view',
      gas: null,
      _isFragment: true
    }
  },
  errors: {},
  events: {},
  structs: {},
  deploy: ConstructorFragment {
    name: null,
    type: 'constructor',
    inputs: [ [ParamType], [ParamType] ],
    payable: false,
    stateMutability: 'nonpayable',
    gas: null,
    _isFragment: true
  },
  _isInterface: true
}

So which one of these is the "real" abi? (The one I can use on etherscan to validate when it asks for ABI), or the one I could use to get a handle to a deployed contract instance using contract = `new ethers.Contract(address, abi, signer)?

the problem is that while hardhat is very handy for development of my smart contracts, I dont want to have deploy it on the front end or backend of my dapp, but the fact that they "extend" ethers.js with all kinds of things that specific only to hardhat, and their "artfacts" including bytecode and apparently abi's can't be used outside of the hardhat context makes life difficult and hard to know which is "real ethers" and what is a hardhat specific thing.

[ricmoo]

The contract.interface is an Interface object, which is a JavaScript object that offers functions like .parseLog and such. If you want the data you can use on Etherscan, ethers provides a .format function, which allows you to output the ABI in various formats, such as JSON (iface.format("json")) or in a human-readable ABI (face.format()) along with a few other options.

An ABI is a description of a thing and has different representations, if you are coming from Web3.js or looking at Etherscan you are most familiar with the JSON format (or as you have above, the parsed JSON). Most users of ethers will use the human-readable formats for serialization.

So, they are both the real ABI. It's like a photo, you might have a printed copy from your printer, it opened in your web browser and the binary content of the PNG file showing on your screen; which of these is the "real" photo? :)

Things are more confused because Hardhat has injected a bunch of things into ether's namespace, so it is sometimes hard for even me to know which things they injected or overwrote. In the future I believe they have committed to keeping a better division from my namespace.

[grapevinegizmos]

Thanks Richard. Never realized there were "many faces of an ABI." When my head stops spinning I"m sure that will come in handy. Just to confirm though, I can use either of these abi formats the context of statement like `let myContract= new Contract(myAddress, myABI, mySigner) and they will all produce the same thing?