Caliper fails after ordererer timeout: Cannot read property 'status' of undefined

[scottoaks17]

Running caliper, the code that submits the transaction to the orderer received a timeout, which caliper did not handle correctly. Instead, it emits this:

2020.02.12-19:29:42.702^[[33m warn ^[[39m [caliper] [adapters/fabric] Broadcast error from orderer.example.com: TIMEOUT
2020.02.12-19:29:42.703^[[31m error^[[39m [caliper] [adapters/fabric] Transaction[8cd0fd3d7e] unexpected error: TypeError: Cannot read property 'status' of undefined
at Fabric._submitSingleTransaction (/path/node_modules/@hyperledger/caliper-fabric/lib/fabric.js:2016:35)

Context

The code from fabric.js is essentially this:

let broadcastResponse;
try {
    let responsePromise = new Promise(async (resolve, reject) => {
         let timeoutHandle = setTimeout(...);
    broadcastResponse = await responsePromise;
} catch (err) {
   // missing the ACK does not mean anything, the Tx could be already under ordering
    // so let the events decide the final status but log this error
    invokeStatus.set(`broadcast_error_${targetOrderer}`, err.message);
    logger.warn(`Broadcast error from ${targetOrderer}: ${err.message)');
} 
if (broadcastResponse.status !== 'SUCCESS') {

When the timeout is thrown, the intent from the comments in the catch block is to continue and look for other events. But immediately after the catch block the code attempts to reference broadcastResponse, which was never set, resulting in a fatal error.

Expected Behavior

Benchmark execution should continue (treating the timeout as an error? Or at least processing the later events as the comment says, though I'm not convinced they are coming.)

Actual Behavior

undefined reference error

Existing issues

None found

Context

Test failed

Your Environment

• Version used: caliper-cli 0.2.0, fabric 1.4.0, grpc 1.14.2
• Environment name and version (e.g. Chrome 39, node.js 5.4): node 10.18.1
• Operating System and version (desktop or mobile): OEL 7.7
• Link to your project:

[aklenik]

@scottoaks17 Nice catch! You're right, we must make sure that the broadcastResponse variable is set.
Would you submit a PR with the fix? :)

(As for the comment in the code, you're right again. Since we use up the entire timeout of the TX for the ordering ACK, it's safe to assume that the TX failed as far as the client is concerned. And benchmarking is all about the client-side perception of requests.)