Add events to transaction submission in support of performance testing

[benjamincburns]

It would be helpful if the PromiEvent that is returned when sending transactions fired off events that provided finer-grained detail on the transaction submission process. There are numerous benefits to this:

• Makes it easier to ensure that transactions are submitted in order (see web3+HttpProvider reusing nonce when doing parallel contract deploy using Promise.all #1846)
• Makes transaction timing in performance benchmarking tools more precise
• Makes it easier to monitor the transaction submission process for debugging purposes

Expected behavior

PromiEvents for transactions would fire the following events

Event	Description
sending	Fired immediately before transmitting the transaction request - connection to provider must be open when this is fired. Intermediate requests such as eth_chainId, eth_estimateGas, or eth_gasPrice must be completed prior this event being fired.
sent	Fired immediately after the request body has been written to the client, but before the transaction hash is received
transactionHash	Behaves as it does today
confirmation	Behaves as it does today, but includes the block hash for the latest block in the event handler arguments
receipt	Behaves as it does today
error	Behaves as it does today

Actual behavior

Events are only fired for transactionHash, receipt, confirmation, and error. Confirmation events don't include the current block hash, meaning that applications must fetch it if they need that information.

Versions

Applies to all versions in existence today (<=v1.2.6, v2.0.0-alpha, and v2.0.0-alpha.1).

Related Issues

• web3+HttpProvider reusing nonce when doing parallel contract deploy using Promise.all #1846
• Ethereum adapter needs better nonce management hyperledger-caliper/caliper#776

[cgewecke]

@benjamincburns Thanks for proposing and for the design work. LGTM.

[benjamincburns]

@cgewecke glad to see you're working on web3 these days! Hope you're doing well!

If you're happy with this I'll go ahead and move forward with a PR. Is web3 on a particular release cadence at the moment? Which branch should I target to minimize the time that it'll take to get this into a release? If I were to get a PR in and approved today, when should I expect that it would be released?

[cgewecke]

@benjamincburns Hi :)

The cadence is slow - Web3 1.x is trying to make changes conservatively. For example, every PR has at least 3 days of open public review and every formal release is preceded by a beta release with a week long "request for comment" .

At the moment we are publishing from 1.x and will hopefully release 1.2.7-rc.0 within a couple weeks.

Fair warning: it's possible that only things currently in the PR queue will be included in the next patch (sorry) but if you'd like to open a PR that would wonderful.

[benjamincburns]

OK, thanks for setting expectations. Fortunately I have a workaround for now for websocket connections so I'm able to move forward with my perf testing in the short term with that. For more info you might want to see my comments on the PR containing my workaround (hyperledger-caliper/caliper#780).

[cgewecke]

Ok awesome! Thanks @benjamincburns.