@hlf-core/transport

The transport in hlf-core is deliberately split into three packages, and before talking about the client it is worth naming the whole trio. @hlf-core/transport-common holds the protocol — envelopes, signature, nonce, constants. @hlf-core/transport-chaincode is the chaincode side. And @hlf-core/transport, which is what we are talking about here, is the client side. The shared package in the middle is not a luxury: it guarantees that the client and the chaincode speak the same language of envelopes.

The main class is TransportFabric, a descendant of TransportImpl from @ts-core. Hence the familiar connect, send, sendListen, and access to api: FabricApiClient. Based on the isReadonly flag, the transport itself chooses whether to call evaluate or submit, so the application code need not think about it. If the chaincode throws a domain error, parseChaincodeError reconstructs it from the Fabric wrapper back into an ExtendedError with a code — that is, in exactly the form in which the handler threw it.

const transport = new TransportFabric(logger, settings);
await transport.connect();
const user = await transport.sendListen(new UserGetCommand(uid));
await transport.sendListen(new UserAddCommand(dto), {userId, signature});

The response to a mutating command does not arrive immediately but from a block, and it is parsed by TransportFabricBlockParser. It turns the block into a typed ITransportFabricBlock and links events to transactions by hash, so that an event acquires a requestId and a validation code. It is by requestId that the client matches the incoming response to the original command.

Batch mode stands apart — TransportFabricBatch and TransportFabricBlockParserBatch. In it, mutating commands do not wait for a response one by one: the chaincode accumulates them and executes them in a single transaction, and the responses arrive later, from the block, as a “hash → response” map. This is the case where we deliberately sacrifice the immediacy of the response for the sake of throughput and endorsement cost. Readonly commands do not get into a batch — they do not need it.

The connection settings of the client transport (ITransportFabricConnectionSettings) add reconnection parameters to the network settings, and here it is worth knowing about one default: isExitApplicationOnDisconnect is enabled, that is, on a loss of connection the process terminates by default. This behavior is reasonable for a service under the supervision of an orchestrator, but you need to know about it in advance.