Page History

...

We are proposing a new transactional API usage template which makes EOS processing safer from handling a mixed mix of fatal and non-fatal exceptions:

...

In the commit phase, we should decide whether to commit or abort transaction based on the previous stage result. In new Producer API, commitTransaction() will be acting like abortTransaction() as it , such that no longer throws non-fatal exceptions. This means any exception caught during the commit phase will be definitely fatal to simplify , so user's error handling experience could be simplified by just doing a controlled shutdown. If the commit failed internally with non-fatal exception but wasn't throwing, the next beginTransaction() will doom to fail non-fatally, causing the `shouldCommit` flag set false, which means the abortTransaction will be triggered automatically in the next iteration.

The only debatable exceptional case is a timeout exception within commit/abort transaction. It could be treated either fatal or not, as strictly speaking producer would have already done the retrying for max.block.ms, so a timeout here may be suggesting a fatal state to a basic user's perspective. We include the timeout handling in the template here just for an example, usually caller level could have more sophisticated handling to do an application level retry if necessary.  

...