Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: invalid object key - from #862

Closed
zemse opened this issue Jun 1, 2020 · 14 comments
Closed

Error: invalid object key - from #862

zemse opened this issue Jun 1, 2020 · 14 comments
Labels
bug Verified to be an issue. fixed/complete This Bug is fixed or Enhancement is complete and published.

Comments

@zemse
Copy link
Collaborator

zemse commented Jun 1, 2020

pragma solidity ^0.6.3;

contract SimpleStorage {
  string value;

  event ValueChanged(address indexed author, string oldValue, string newValue);

  constructor(string memory _value) public {
    setValue(_value);
  }

  function getValue() view public returns (string memory) {
    return value;
  }

  function setValue(string memory _value) public {
    emit ValueChanged(msg.sender, value, _value);
    value = _value;
  }
}

Deploying the contract

const provider = new ethers.providers.Web3Provider(
  ganache.provider()
);
const SimpleStorageContractFactory = new ethers.ContractFactory(
  simpleStorageJSON.abi,
  simpleStorageJSON.evm.bytecode.object,
  provider.getSigner(accounts[0])
);
simpleStorageInstance = await SimpleStorageContractFactory.deploy(
  'hello world'
);

Then the below line throws

const receipt = await simpleStorageInstance.functions.setValue('hi');

Error stack:

Error: invalid object key - from (argument="transaction:from", value={"data":"0x93a09352000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000026869000000000000000000000000000000000000000000000000000000000000","to":"0x269BedBF7938236aA99c34f57d2625CD9e2A41F3","from":"0xD8d15380470E2d3F5d8FeddF9eE6171C6c08CFEf","gasLimit":{"_hex":"0x8d4f","_isBigNumber":true}}, code=INVALID_ARGUMENT, version=properties/5.0.0-beta.143)
      at Logger.makeError (node_modules/@ethersproject/logger/lib/index.js:178:21)
      at Logger.throwError (node_modules/@ethersproject/logger/lib/index.js:187:20)
      at Logger.throwArgumentError (node_modules/@ethersproject/logger/lib/index.js:190:21)
      at /Users/sohamzemse/soham/kmpards/ESNCoreProjects/plasma/node_modules/@ethersproject/properties/lib/index.js:92:20
      at Array.forEach (<anonymous>)
      at Object.checkProperties (node_modules/@ethersproject/properties/lib/index.js:90:25)
      at Function.JsonRpcProvider.hexlifyTransaction (node_modules/@ethersproject/providers/lib/json-rpc-provider.js:519:22)
      at /Users/sohamzemse/soham/kmpards/ESNCoreProjects/plasma/node_modules/@ethersproject/providers/lib/json-rpc-provider.js:155:52
      at processTicksAndRejections (internal/process/task_queues.js:97:5)

The line throws on ethers v5, while it works for ethers v4.

To reproduce with the files:

$ npx create-solidity-project testproject
$ cd testproject
$ npm test

The above line will prepare you a quick simple project with ethers v5 (that does the above) to reproduce the error.

@ricmoo This might be related to #321. Looks like the contract along with JsonRpcProvider is injecting a from, and the checkProperties is not happy with the from. Can you please have a look?

@ricmoo ricmoo added investigate Under investigation and may be a bug. on-deck This Enhancement or Bug is currently being worked on. labels Jun 1, 2020
@ricmoo
Copy link
Member

ricmoo commented Jun 1, 2020

Quick question. Are you using the most recent version of v5? This part has undergone a lot of turmoil the last few days.

Regardless, I’ll look into this shortly.

@zemse
Copy link
Collaborator Author

zemse commented Jun 2, 2020

Yes, I’ve tried the error is also on beta 190. Expected that 190 might have caused this because I read a point major refactor in contract code.

So, yesterday I tried a quiet a few versions to find that it also gives error on beta 141. v5 earlier than beta 141 gives some stack error about word lists so I couldn’t get it working.

@nick
Copy link

nick commented Jun 2, 2020

I am seeing this too. beta-189 works fine.

@crazyrabbitLTC
Copy link

I can confirm that I am seeing this on "ethers": "^5.0.0-beta.189",

@ricmoo
Copy link
Member

ricmoo commented Jun 2, 2020

Thanks. Yeah, looking into it now... :)

@ricmoo
Copy link
Member

ricmoo commented Jun 3, 2020

Found the issue, just building out the reproduction script right now.

@ricmoo ricmoo added bug Verified to be an issue. and removed investigate Under investigation and may be a bug. labels Jun 3, 2020
@ricmoo
Copy link
Member

ricmoo commented Jun 3, 2020

This should be fixed in 5.0.0-beta.191. Try it out and let me know. :)

@nick
Copy link

nick commented Jun 3, 2020

Seems to have fixed it for me - thanks

@zemse
Copy link
Collaborator Author

zemse commented Jun 3, 2020

Thanks for the fix @ricmoo. However, it's weird to me that beta.190 and older versions aren't giving any error after your beta.191 fix.

Just curious here about this why old versions are not giving error. Is this due to internal packages which makes older versions of packages install latest internal packages?

@ricmoo
Copy link
Member

ricmoo commented Jun 3, 2020

Yeah, there was a major internal refactor of Contract, which is what caused it. The older versions had a massive “runMethod” function, which wrapped 5 completely different things (which happen to have a lot of overlap) and made a lot of use of the TypeScript any. It was kinda fragile and hard to visually inspect the correct thing was happening.

The new code is now 5-ish separate functions which call each other and expose the various stages directly.

@ricmoo
Copy link
Member

ricmoo commented Jun 3, 2020

Oh! Just realized what you meant.

So, ethers is a large collection of internal modules. Since the contract module was the problem and since ethers will pick up the most recent version of contract, older versions will pick that up.

To lock the sub-module versions, you can use a package-lock and npm ci (instead of npm install).

Does that make sense? I can give better examples if you want. :)

@ricmoo ricmoo added fixed/complete This Bug is fixed or Enhancement is complete and published. and removed on-deck This Enhancement or Bug is currently being worked on. labels Jun 3, 2020
@ricmoo
Copy link
Member

ricmoo commented Jun 3, 2020

Closing this now, but if you have any further issues, please re-open.

Thanks! :)

@ricmoo ricmoo closed this as completed Jun 3, 2020
@zemse
Copy link
Collaborator Author

zemse commented Jun 5, 2020

Thanks for the explanation, it cleared the doubts I had.

And I'm sorry if you thought I didn't reply quickly. Actually, 2 days ago we had a cyclone here and electricity was out due to damage and it just got fixed. My last message happened to be the last one I did during the calamity just before the power outage. Now it's alright here but TBH all this time offline I was eagerly waiting for coming online again to check the reply. And I'm thankful for the time you give to come up with quick fixes.

@ricmoo
Copy link
Member

ricmoo commented Jun 5, 2020

@zemse No worries. You never need to reply. I just worry sometimes about closing an issue too early on people. If something seems resolved I'll close it eventually. Right now I'm going through a little more aggressively than usual, because I'm planning tome v5 out of beta in a week, and am trying to clear out the issues a bit so I can make sure I haven't missed any features or issues people have had.

Glad you're safe, and make sure you stay safe. That's more important than adding "issue resolved" metadata to an issue. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Verified to be an issue. fixed/complete This Bug is fixed or Enhancement is complete and published.
Projects
None yet
Development

No branches or pull requests

4 participants