This happend on my dev server and not locally, because the dev update packages and we relied on not a set version of web3. So the error did not happen locally until I deleted all nodemodules and installed again. Forgot to check what version I had locally.
But I expect to
The transaction to go through. It has worked before, but suddenly with some of the new changes it did not work. First of all the main problem was that the ._address property of the contract object was gone in an update, so changed it to address.
But this code is suppose to work, and is not changed
const executeAddAttributeTransaction = async (contract, identity, sig, attribute, value, validity, payer) => {
return new Promise(async (resolve, reject) => {
try{
const web3 = ethereum.web3;
const nonce = await web3.eth.getTransactionCount(payer);
const txObj = await contract.methods.setAttributeSigned(identity, sig.v, sig.r, sig.s, attribute, value, validity);
const tx = txObj.send({from: payer, gas:200000,});
tx.on('transactionHash', (hash) => {
resolve({
hash,
nonce,
})
});
tx.on('error', (e, outOfGasReciept) => {
logger.error(e.message, {error: e, outOfGasReciept: outOfGasReciept,});
reject(e);
});
} catch(e) {
reject(e);
}
})
Throwing an error deep down in the library.
Happening on this code
var inputTransactionFormatter = function inputTransactionFormatter(txObject, moduleInstance) {
txObject = txInputFormatter(txObject);
if (!isNumber(txObject.from) && !isObject(txObject.from)) {
if (!txObject.from) {
--->txObject.from = moduleInstance.defaultAccount;
}
if (!txObject.from && !isNumber(txObject.from)) {
throw new Error('The send transactions "from" field must be defined!');
}
txObject.from = inputAddressFormatter(txObject.from);
}
return txObject;
};
Then it should fail on send at the stage i pointed out
'TypeError: Cannot create property \'from\' on string \'0xf9018c820173843b9aca0083030d4094dca7ef03e98e0dc2b855be647c39abe984fcf21b80b90124123b5e98000000000000000000000000d9419a2365da3a7fb8c840f5bb03d5407c953f41000000000000000000000000000000000000000000000000000000000000001bc47e91cd456927ce28008c3c09b16868f887a102e03d61ce4e0960c9edadc2007932371e69ebd2d59e842d78ef86f430499cb558aed461d400c7e39d82d45f536469642f7376632f6e616d65000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000eaf625800000000000000000000000000000000000000000000000000000000000000000361646600000000000000000000000000000000000000000000000000000000002ca05e07e3f14023688f0edb7b6ad44ac99a1df9ae550a47059be112df38fbbac97ea0666937d68cfbecdd4cc1a705073ea67f5d86a26a46a2cbac894bbda04be5c048\'\n at Object.inputTransactionFormatter (/Users/snorre/code/diwala/cert-platform/packages/api/node_modules/web3-core-helpers/dist/web3-core-helpers.cjs.js:78:21)\n at SendContractMethod.beforeExecution (/Users/snorre/code/diwala/cert-platform/node_modules/web3-core-method/dist/web3-core-method.cjs.js:1075:44)\n at SendContractMethod.execute (/Users/snorre/code/diwala/cert-platform/node_modules/web3-core-method/dist/web3-core-method.cjs.js:1006:12)\n at /Users/snorre/code/diwala/cert-platform/node_modules/web3-core-method/dist/web3-core-method.cjs.js:1100:85\n at <anonymous>\n at process._tickCallback (internal/process/next_tick.js:118:7)'
MacOS
Node 9.10
NPM 6.4.0
Web3 - 1.0.0-beta46
Also tried earlier versions, but my installment procedure might be broken, because it happend there too.
@pedroraft, @ates, @noeRIs, have you experinecd this, did you guys just set down the library version or what made you continue around this problem?
This problem gone when I downgrade web3 to 1.0.0-beta.35
@nivida I think this might be quite problematic
same issue happened to me with 1.0.0-beta.46. The "from" field somehow disappeared.
@vongohren Sorry was on vacation for a week. Will fix it asap and release it within the next beta version.
@nivida ah no worries, and no need to say sorry for vacations! They are important 馃槃 But glad to hear and look forward to a fix! When is the next beta version expected to release?
I've just had a closer look at your example:
const executeAddAttributeTransaction = async (contract, identity, sig, attribute, value, validity, payer) => {
return new Promise(async (resolve, reject) => {
try{
const web3 = ethereum.web3;
const nonce = await web3.eth.getTransactionCount(payer);
const txObj = await contract.methods.setAttributeSigned(identity, sig.v, sig.r, sig.s, attribute, value, validity);
const tx = txObj.send({from: payer, gas:200000,});
tx.on('transactionHash', (hash) => {
resolve({
hash,
nonce,
})
});
tx.on('error', (e, outOfGasReciept) => {
logger.error(e.message, {error: e, outOfGasReciept: outOfGasReciept,});
reject(e);
});
} catch(e) {
reject(e);
}
})
The correct way to do this would be:
const executeAddAttributeTransaction = async (contract, identity, sig, attribute, value, validity, payer) => {
try {
const web3 = ethereum.web3;
const nonce = await web3.eth.getTransactionCount(payer);
const receipt = await contract.methods.setAttributeSigned(identity, sig.v, sig.r, sig.s, attribute, value, validity).send({
from: payer,
gas: 200000
});
return {
hash: receipt.transactionHash,
nonce
};
} catch (e) {
logger.error(e.message, {error: e, outOfGasReciept: outOfGasReciept});
throw e;
}
};
The reason for needing the transaction hash by an event, is that await forces me to wait for the whole transaction to finish, which locks up the code.
I want a fast return and tackle the error after if there is any.
@nivida but I will try it tomorrow morning! But it has been working before, and maybe some versions broke this and your suggestion works. But as stated, I did on for a reason, and the await before set attributes is not needed, it must be code that just got left there without any reason
Okay then I think this should work:
const executeAddAttributeTransaction = (contract, identity, sig, attribute, value, validity, payer) => {
return new Promise(async (resolve, reject) => {
const nonce = await ethereum.web3.eth.getTransactionCount(payer);
contract.methods.setAttributeSigned(identity, sig.v, sig.r, sig.s, attribute, value, validity)
.send({
from: payer,
gas: 200000
})
.on('transactionHash', (hash) => {
resolve({
hash,
nonce
});
}).on('error', (e, outOfGasReciept) => {
logger.error(e.message, {error: e, outOfGasReciept: outOfGasReciept});
reject(e);
});
});
};
I will close this issue now because it is an implementation issue.
@nivida this does not any difference than what I do, I still get the errror.
There is no difference if I do chaining or instansiate an object I call "send" on, still chaining, which I again attach "on" listeners too. The problem is that "on error" returns the mentioned error and I believe it is something further down in the stack, and not my implementation. It thinks from is something completly different than what it is suppose to be!
I just downgraded to beta35, and the same code works there, so there is something that has broken through out the updates.
As I mentioned also, _address attribute has also changed to address at some point, so had to change that in an helper method for this method.
I conclude with that this is not an implementation error, rather a breaking change that is not been clarified.
Hay,
I've just tested it again with a contract and version beta.46:
var web3 = new Web3(window.web3.currentProvider);
var contract = new web3.eth.Contract(abi, '0x0ff095b6b4d215d91b4c1d7fce025a9d72afff22');
function sendIt() {
return new Promise((resolve, reject) => {
contract.methods.transfer('0x24BBE93E1D5b43233D921C9c73E15e8576bD7Be1', 1000)
.send({from: '0x9CC9a2c777605Af16872E0997b3Aeb91d96D5D8c'})
.on('transactionHash', (hash) => {
console.log(hash);
resolve(hash);
})
.on('error', (e, outOfGasReciept) => {
console.log(e);
console.log(outOfGasReciept);
reject(e);
});
});
}
document.getElementById('transfer').addEventListener('click', () => {
sendIt().then(console.log).catch(console.log);
});
This does immediately resolve with an transactionHash:

@vongohren The _address property was never a part of the official API as you can see here. A property with an underline means it is a private property and you probably shouldn't use it.
@nivida im sorry but I dont want to be pushy, but I dont think you are trying to work with me on this, just trying to close this and blame it on a mistake I have done.
I tried again, with updated library, same piece of code.
The address field mentioned earlier, has always been the same value, doesnt matter if it is _address or address in this discussion, it is just the contract address, and that has been the same all along.
But the from field is beeing set to some long string deep down in the code:
Cannot create property 'from' on string '0xf9018c820174843b9aca0083030d4094dca7ef03e98e0dc2b855be647c39abe984fcf21b80b90124123b5e98000000000000000000000000d9419a2365da3a7fb8c840f5bb03d5407c953f41000000000000000000000000000000000000000000000000000000000000001bc47e91cd456927ce28008c3c09b16868f887a102e03d61ce4e0960c9edadc2007932371e69ebd2d59e842d78ef86f430499cb558aed461d400c7e39d82d45f536469642f7376632f6e616d65000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000eaf625800000000000000000000000000000000000000000000000000000000000000000361646600000000000000000000000000000000000000000000000000000000002ba05dfbca4f7e2e4cfc1be530da6bd257aee9d64279dc2cafb1debb99008412c906a03bf42445d4d091a7d507d9063c4e2f0165a61f2e613c30160d9cab8f022fc8ad'
Attached is the values of the current call that failes:

So I dont understand how the from field is trying to set the value to a data string, where you can see the identity value is clearly apart of the long string trying to be set to from. As well as the validity value which in this context is: "0x0000000000000000000000000000000000000000000000000000000eaf625800"
So what is happening I wonder?
@nivida i agree with @vongohren, it seems like a bug not a support issue, working on version 35 and not 46 is a big indicator i think.
Pardon my ugly test code, but this works on 35 and not 46, same error as @vongohren
const web3 = new Web3("http://1...7:8...");
const acc = web3.eth.accounts.privateKeyToAccount(
"0xb3b643459ab....9f78ba2ecf580ea3d"
);
web3.eth.accounts.wallet.add(acc);
const contents = fs.readFileSync("src/tokens/token.json");
const jsonContent = JSON.parse(contents.toString());
const ABI = jsonContent["abi"];
const bytecode = jsonContent["bytecode"];
const contract = new web3.eth.Contract(ABI);
const deploy = contract.deploy({
data: bytecode,
arguments: ["aaaa", "aaa", 8, 0]
});
deploy.estimateGas({ from: acc.address }, (x, gas) => {
console.log(gas);
deploy
.send({ gas, from: acc.address })
.then(newContract => {
console.log(newContract.options.address);
})
});
@nivida im sorry but I dont want to be pushy, but I dont think you are trying to work with me on this, just trying to close this and blame it on a mistake I have done.
This is not true, I've tested it in several ways but never get that error. That's why I wrote an example code for you which worked for me and closed this issue. I never wanted to blame you.
Instead of uploading screenshots here and adding of other code examples. Would I think is it the best way to reproduce this if you create a short repository where this error happens.
As it looks like is this issue the same as https://github.com/ethereum/web3.js/issues/2341 and will be fixed in the next release. The problem was not the execution of a contract method itself, the real issue was that the parsing of the parameters had a bug because it signed the transaction locally.
Sorry for the troubles but it was hard to reproduce the problem you had. I will close this issue because it got referenced in issue #2341.
@nivida thanks for that follow up, I will try out when the next release comes out. When is it expected to come out?
I also got the same error with version 46. It is working well with version 35.
web3.eth.sendTransaction({ from: '0x285ec075d1ff575ec8e21fc0f54b1ac0382b9e6c', to: '0x370B5afb7Be5b6fAFfD320Fd7025d8956667Fa5e', value: '1000000', gas: 210000}).then(consol
e.log);
(node:91887) UnhandledPromiseRejectionWarning: TypeError: Cannot create property 'from' on string '0xf8678084773594008303345094370b5afb7be5b6faffd320fd7025d8956667fa5e830f42408029a01b620ea759e7ec37d46e56936f3347528f7223b3b6d53ff8e537828203bdcc85a03ec1e75f39ae6f15df8d485ddf8eda7dec81fce5f330ea3198a0756c87975cd9'
at Object.inputTransactionFormatter (/node_modules/web3-core-helpers/dist/web3-core-helpers.cjs.js:78:21)
at SendTransactionMethod.beforeExecution
sendTransaction() is not working in the new version.
@dev-l33 version 36 works well to, and if you have a typescript base, you need to use 36. But there will be a new release soon i hope
@vongohren what does it mean when you say use 36 ? base 36??
@shivan4030 I think that was that I was using release: web3.js 1.0.0-beta.36
Most helpful comment
@dev-l33 version 36 works well to, and if you have a typescript base, you need to use 36. But there will be a new release soon i hope