Parity-ethereum: Javascript API: invalid params on contract creation

[asmello]

I'm running:

• Parity version: Parity/v1.7.0-beta-5f2cabd-20170727
• Operating system: Linux (Ubuntu 16.04 x64)
• And installed: via installer (apt)

let web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

let compiledCode = solc.compile(code);
let abiDefinition = JSON.parse(compiledCode.contracts[':Voting'].interface);
let VotingContract = web3.eth.contract(abiDefinition);
let byteCode = compiledCode.contracts[':Voting'].bytecode;

let deployedContract = VotingContract.new(['Rama','Nick','Jose'],{data: byteCode, from: web3.eth.accounts[0], gas: 4700000});

This last line fails with a JSON invalid params error. This is because the parser expects data's byte string to be prefixed with '0x', which doesn't apply to solc's bytecode. This wouldn't be considered a bug, except this requirement is not made clear by the documentation and other implementations of the same API relax it.

[5chdn]

What do you suggest?

[tomusdrw]

All hex-encoded fields (bytes, uint) are required to be prefixed with 0x - it has been like that since version 1.0 and is clearly documented in JSONRPC docs.

IIRC the requirements are relaxed when running with --geth, but it also produces warnings that this behaviour will be removed in future.

[asmello]

@tomusdrw fair enough, it does make more sense to prefix with 0x for all data, but this is in the lower level JSONRPC documentation, not in the Javascript docs, and it's very hard to trace this bug to its cause. If it was a corner case I wouldn't even have opened this issue, but the Parity implementation was failing with very simple demo code when both Geth and TestingRPC didn't even give me a warning.

@5chdn I suggest some form of special treatment is given to this kind of encoding error, in the JS API level. The JS API is higher level and already performs type conversion when convenient, so I wouldn't find it unreasonable for it to be more relaxed with the .new() input either (by prefixing the string itself when required). Either that, or some highlighted addition to the JS docs explaining the encoding requirement would make me satisfied.

[tomusdrw]

@asmello Yeah, imho the web3 library should add the prefixes if needed, since it's handling those conversions for other types. The RPC is as strict as possible to prevent some undefined behaviour and we prefer to keep it this way.
You can check parity.js library which is a web3 replacement with Promises support. It does prefix the data correctly.

[asmello]

@tomusdrw thanks, I didn't know about parity.js - I suppose it's less portable, but I find the Promises support to be very interesting.

Actually, now that you mention it, the JS API is not mentioned anywhere in the docs except in the Basic Usage page, and that one just points to the Ethereum docs. Which means I've probably just been using the vanilla web3.js implementation, haven't I? I should probably fill in an issue there instead, then.

I suppose it's still relevant to highlight the strict behavior in the JSONRPC docs, or point to parity.js as an alternative to web3.js in the Parity docs. I'll leave the issue open for now, with that request in mind, but feel free to re-tag it as appropriate.