Errors Management

[ipapandinas]

Errors are not well managed in the current version of the SDK.
There is a lack of information as @ogous pointed out in this issue #110.

The purpose of this discussion is to open a space of debate in order to design proper error management codes.
In the end we should come up with:

• Set a proper convention naming to separate chain errors from helpers errors (e.g. COLLECTION_CONVERSION_ERROR is related to a parsing error, COLLECTION_NOT_FOUND is related to a storage error, EXTRINSIC_FAILED is related to a chain error)
• Complete EXTRINSIC_FAILED chain errors with the details coming from the chain and return the extrinsic hash.
• Handle errors on transactions batching: return a list of the failed extrinsics (details message + extrinsic hash)

[ogous]

Polkadot.js api methods return SubmittableExtrinsic type, check for parameters but does not have null check or type check.

For example

const transferHex = await api.tx.balances.transfer(TO,VALUE).toHex();

TO and VALUE can be null and any type, it will create SubmittableExtrinsic and hex without throwing any error.

It would be good to add null and type check to TX methods on ternoa-js layer.

[ipapandinas]

On the first version of the SDK we used to do several checks: integrity checks + chain storage checks.
We challenged checks in this issue #14 and decided to remove all for chain TX helpers, so native chain error messages are returned to the user.

Note that only few specific checks will be kept on additional custom helpers (e.g. ipfsFileUpload)

[Victor-Salomon]

@ogous a first couple of information/precisions as I'm moving forward into the error management improvements.
It might fits to the issue #110 you open.

Regarding the issue about the Error Details/logging :

We have added a better error logging when ExtrinsicFailed event error is provided. It will be released within the upcoming 1.4.0-Alpha release. Now, when an extrinsic failed error appear, you will have an explicit error detail.
See commit 897bf48

Regarding the issue about the Batch Issue :

You might be aware of it but here is a quick reminder in our github wiki about the Batch/BatchAll functions and their differences.
BatchAll might be closer from the MongoDB's case you provided in the issue #110. Understanding the behaviour of those two functions is very important.

When the classic Batch find an error (a tx failed among all the tx submitted):

• The batch stops where it is, and keeps the firsts validated tx.
• The chain provide a list of events : For each successfull events the chain provides a tx event (ex: nft.CollectionCreated) + an utility.ItemCompleted event, until the failed event : A BatchInterrupted event for the failed tx is thrown and sdk should provide the detail and index of the failed extrinsic.
• Since BatchTx Extrinsic is considered as successfull even when interrupted, it does not mean that all tx are validated: So the chain provide the ExtrinsicSuccess event anyway. A good practice would be to monitor BatchCompleted and check with our findEventfunction if a BatchInterruptedEvent has been thrown within the Batch. If a BatchCompleted event is available, it means that Batch has not been interrupted. Otherwise, the batch has been interrupted at some point. Check the event list.

When the BatchAll function encounter an error (a tx failed among all the tx submitted):

• the chain only provides an ExtrinsicFailed event with the first error detail encountered.
• the chain revert the firsts validated extrinsics : Meaning the chain status is still the same as before. Nothing has been validated (all tx are reverted).

When aBatchAll or Batch function is completed without error : An utility.BatchCompleted event is provided by the chain.

The general rule of thumb is to always use the batchAll transaction.

We are going to improve the BatchInterrupted event and provide more details when it appears.

[ogous]

@Victor-Salomon thanks for the clear expression. That is exactly what is needed to done imo.

In our latest use case, we need batch instead of batchAll because we need to know also every successful transaction and it is inefficient to rollback any successful transaction and can be dangerous because it can generate bottlenecks with infinite failing batches.

Exciting to use alpha version. Thanks guys! 🙌🏻

[ogous]

@Victor-Salomon @ipapandinas when could we use this release?

[Victor-Salomon]

Hi @ogous, sorry for late answer : 1.4.0Alpha version is targetted early next week.

[ipapandinas]

These improvements are available in the fresh deployed version 1.3.1-r0 🚀
Thank you @ogous for reporting these issues ✌️