Request for an official support to calculate the Transaction hash

[andys-ab]

Right now, there isnt a way to get the transaction hash before it is being sent to the blockchain. The only way to do it is to take out a part of the code in @onflow/sdk to create a transaction object and apply a SHA3 onto the transaction object to get the transaction hash. Then every time the sdk updates, that part of code needs to be updated as well. That would be great if there is an official support for this.

Pre-calculating the transaction hash is important. This allows us to perform error recovery if there are any network connection issues during the submission of the transaction.

[orodio]

@andys-ab this has come up a couple times now, thanks for creating an issue for it.

Would something like this work?

var txId = await fcl.send([
  fcl.transaction(CODE),
  fcl.payer(fcl.authz),
  fcl.proposer(fcl.authz),
  fcl.authorizations([fcl.authz]),
  
  // we would add this ability as a middleware
  // It would be executed/resolved right before transaction is sent
  // it would wait for the callback function to complete before sending the transaction
  // if the callback throws an error it would halt the transaction
  fcl.preSendCheck(async voucher => {
    // we would supply the ability to go from the voucher to the hash (txId)
    var txId = fcl.voucherToTxId(voucher)
    
    // you can make an async to your backend to keep track of the hash
    await sendHashToBackend(txId)
    
    // could throw an error here if you wanted which would halt the transaction.
  })
])

For safety you shouldnt be able to modify the voucher or the transaction that will be sent at this point, so its really just giving you a hook that enables you to pause before sending, do your business, and then continue if everything is good or throw an error.

with the newer mutate syntax i would imagine it would look something like this

var txId = await mutate({
  cadence: CODE,
  preSendCheck: async voucher => {
    // ... do your stuff here
  }
})

Would the above solve your issues? If it doesn't can you elaborate on why it wouldn't.

[andys-ab]

Hi @orodio,

This would definitely work for us. One thing bothers me is the voucher variable. Are you referring to the object that includes the payloadSigs and the envelopeSigs ? if yes, I think the name voucher is a bit confusing. Apart from this, everything looks good.

So do you have an estimated time to roll this out? Just want to have an estimation about having this update in my production servers.

Thanks.