sync contract.method.sendTransaction returns undefined

[jesuscript]

Can we please make it return the transaction address? Especially since the docs say that it should: https://github.com/ethereum/wiki/wiki/JavaScript-API#returns-42

[kumavis]

The sendTransaction api call must await user input to confirm the transaction before it could return any useful information. Don't use sync sendTransaction if you care about the resulting information.

[jesuscript]

This is not how sendTransaction works. Can we please reopen this?

[jesuscript]

https://github.com/ethereum/web3.js/pull/222/files - this is what I'm talking about

[kumavis]

@jesuscript a sendTransaction call from a dapp is a suggestion to the dapp browser to make a transaction. We assume dapps are evil, therefore they can't just send stuff to the blockchain w/o user confirmation.

[jesuscript]

This is how AZ works. The situation with Geth is different: sendTransaction is (sort of) instantaneous: it's either rejected off the bat if you haven't unlocked your primary or accepted immediately.

The bigger issue here is this: do you want to keep synchronous sendTransaction calls? In which case might as well make them work right.

Or do you actually want to drop them because quite frankly blocking calls in js are nonsense?

[debris]

This is how AZ works. The situation with Geth is different...

That's true. Currently if we are creating a contract, AZ returns new contract address . Otherwise it returns nothing. Meanwhile geth returns new contract address or transaction hash.

We will unify this soon. web3.eth.sendTransaction will always return tx hash. I will let you know when this will happen. I will also prepare some migration guide, cause it will certainly break a lot of dapps.

[kumavis]

For the record, Vapor will always return undefined for synchronous sendTransaction, due to the limitations of faking synchronous behaviour.
Though I don't expect this to influence api design.

[frozeman]

its fixed in develop -> that it will also return the txhash when calling sync.

I'm working on a reliable solution to deploy contracts and getting its address, as it seems for now, you need to a custom event to the constructor.

An example would be (Please threat that as a rough draft):

// Soldity contract

event Created(bytes32 indexed identifier);

contract MyContract {
    function MyContract(bytes32 identifier) {
        Created(identifier);
    }
}



// JS create contract
var MyContract = web3.eth.contract(abi);
var myContractInstance = MyContract.new('xyz1234', {from: ..., data: ..., gas: 123456})
var createdAtBlock = web3.eth.blockNumber;


// JS listen for created log
var Created = web3.eth.filter({
    topics: [null, 'xyz1234'],
    fromBlock: createdAtBlock,
    toBlock: 'latest'
}));
Created.watch(function(error, log) {
    if(!error) {
        console.log('Contract created on '+ log.address);

        myContractInstance.address = log.address;

        // remove filter
        Created.stopWatching();
    }
});


// JS watch for the last next 12 blocks if the code is still at the address
web3.eth.filter('latest').watch(function(e, blockHash){
    if(!e) {
        var block = web3.eth.getBlock(blockHash);
        if(block.number - createdAtBlock < 12) {
            // check if contract stille exists, if show error to the user
            if(web3.eth.getCode(myContractInstance.address).length === '0x')
                alert('Contract Gone!');
        }
    }
});

[jesuscript]

@frozeman Thanks for the example! However, my use case that caused an issue was related to myContract.myMethod.sendTransaction usage rather than MyContract.new.

How do you track a specific transaction with filter.watch without using it's address?

[frozeman]

use go, and you get the txhash :)
This one you can track then. But again we need to unify that, meaning always returning the tx hash.

But the tx hash is also not set in stone, as nonce or gas changes would invalidate the hash and create a new one

[kumavis]

Oh if we're just returning a 'guess' then I can provide that behaviour in Vapor, but that seems dangerous. Seems like it would be most useful and least dangerous to have the synchronous method call return nothing, and the async call return the correct information after it has been sealed in a block (though, forks could still invalidate things)

[frozeman]

Closing this as its fixed in develop