Adds the task future to the flush future so that doFlush completes only after future has completed. Logs an error if the future fails with an exception.

Adds the task future to the flush future so that doFlush completes only after future has completed. The caller is responsible for logging any exceptions thrown inside the future.

Blocks until all earlier tasks have completed and then prevents further tasks from being run.

closeAsync asynchronously releases resources held by a future

Future which is completed when the client is not functional any more and is ready to be closed. The value with which the future is completed will indicate the reason for completion.

Returns a future that completes after all added futures have completed. The returned future never fails.

Returns a future that completes after asynchronous processing has completed for all events whose synchronous processing has been completed prior to this call. May complete earlier if event processing has failed.

Provides a value for max-sequencing-time to use for sendAsync if no better application provided timeout is available. Is currently a configurable offset from our clock.

Generates a message id. The message id is only for correlation within this client and does not need to be globally unique.

Check whether we're closing. Susceptible to race conditions; unless you're using using this as a flag to the retry lib or you really know what you're doing, prefer performUnlessClosing and friends.

track running futures on shutdown

set to true to get detailed information about all futures that did not complete during shutdown. if set to false, we don't do anything.

Performs the task given by f unless a shutdown has been initiated. The shutdown will only begin after f completes, but other tasks may execute concurrently with f, if started using this function, or one of the other variants (performUnlessClosingF and performUnlessClosingEitherT). The tasks are assumed to take less than closingTimeout to complete.

DO NOT CALL this.close as part of f, because it will result in a deadlock.

Performs the EitherT[Future] given by etf unless a shutdown has been initiated, in which case the provided error is returned instead. Both etf and the error are lazy; etf is only evaluated if there is no shutdown, the error only if we're shutting down. The shutdown will only begin after etf completes, but other tasks may execute concurrently with etf, if started using this function, or one of the other variants (performUnlessClosing and performUnlessClosingF). The tasks are assumed to take less than closingTimeout to complete.

DO NOT CALL this.close as part of etf, because it will result in a deadlock.

Performs the Future given by f unless a shutdown has been initiated. The future is lazy and not evaluated during shutdown. The shutdown will only begin after f completes, but other tasks may execute concurrently with f, if started using this function, or one of the other variants (performUnlessClosing and performUnlessClosingEitherT). The tasks are assumed to take less than closingTimeout to complete.

DO NOT CALL this.close as part of f, because it will result in a deadlock.

Register a task to run when shutdown is initiated.

You can use this for example to register tasks that cancel long-running computations, whose termination you can then wait for in "closeAsync".

Sends a request to sequence a deliver event to the sequencer. If we fail to make the request to the sequencer and are certain that it was not received by the sequencer an error is returned. In this circumstance it is safe for the caller to retry the request without causing a duplicate request. A successful response however does not mean that the request will be successfully sequenced. Instead the caller must subscribe to the sequencer and can observe one of the following outcomes:

1. A deliver event is sequenced with a messageId matching this send. 2. A deliver error is sequenced with a messageId matching this send. 3. The sequencing time progresses beyond the provided max-sequencing-time. The caller can assume that the send will now never be sequenced. Callers should be aware that a message-id can be reused once one of these outcomes is observed so cannot assume that an event with a matching message-id at any point in the future matches their send. Use the sendTracker to aid tracking timeouts for events (if useful this could be enriched in the future to provide send completion callbacks alongside the existing timeout notifications). For convenience callers can provide a callback that the SendTracker will invoke when the outcome of the send is known. However this convenience comes with significant limitations that a caller must understand:

• the callback has no ability to be persisted so will be lost after a restart or recreation of the SequencerClient
• the callback is called by the send tracker while handling an event from a SequencerSubscription. If the callback returns an error this will be returned to the underlying subscription handler and shutdown the sequencer client. If handlers do not want to halt the sequencer subscription errors should be appropriately handled (particularly logged) and a successful value returned from the callback.
• If witnessing an event causes many prior sends to timeout there is no guaranteed order in which the callbacks of these sends will be notified.
• If replay is enabled, the callback will be called immediately with a fake SendResult. For more robust send result tracking callers should persist metadata about the send they will make and monitor the sequenced events when read, so actions can be taken even if in-memory state is lost.

Create a subscription for sequenced events for this member, starting after the last event in the com.digitalasset.canton.store.SequencedEventStore up to priorTimestamp. A sequencer client can only have a single subscription - additional subscription attempts will throw an exception. When an event is received any send timeouts caused by the advancement of the sequencer clock observed from the event will first be raised to the timeoutHandler, then the eventHandler will be invoked.

If the com.digitalasset.canton.store.SequencedEventStore contains events after priorTimestamp, the handler is first fed with these events before the subscription is established, starting at the last event found in the com.digitalasset.canton.store.SequencedEventStore.

Create a subscription for sequenced events for this member, starting after the prehead in the sequencerCounterTrackerStore.

The eventHandler is monitored by com.digitalasset.canton.sequencing.handlers.CleanSequencerCounterTracker so that the sequencerCounterTrackerStore advances the prehead when (a batch of) events has been successfully processed by the eventHandler (synchronously and asynchronously).