Non-serializable TransactionVerificationExceptions

Description

Two of the exceptions subclassing TransactionVerificationException defined in net.corda.core.contracs.TransactionVerificationException are not serializable, and do not have tests in TransactionVerificationExceptionSerializationTest. Exceptions of this kind need to be serializable so that their details can be reported to an RPC client.

For an exception to be serializable, there must be a readable property (either a public field or a "getter" method) corresponding to each of the named arguments of the constructor used for deserialization (the primary constructor, or a secondary constructor annotated with @ConstructorForDeserialization ). If constructor arguments are marked as val then a getter is generated automatically.

These two classes do not meet that contract, and are not serializable:

We probably do not want to be serializing StateRef and NetworkParameters anyway, since they are only being used to construct the exception message. A good solution here would be to make the primary constructor accept a String message argument (which is then passed through to the superclass constructor), and provide a secondary constructor which constructs the message, e.g.

The serialization engine will then be able to use the public properties txId and message to populate the arguments of the primary constructor, while client code will be able to use the secondary constructor to build the error message from the state ref and network parameters.

Both of these classes should also have corresponding tests in TransactionVerificationExceptionSerializationTest verifying that they can be roundtrip-serialized.

Status

Assignee

Alexey Chernikov

Reporter

Dominic.Fox@r3.com

Priority

Medium

Fix versions

Ported to...

None

Feature Team

Kernel Group

CVSS Vector

None

Severity

Medium

Affects versions

Configure