Acknowledge that we have successfully processed all events up to and including the given timestamp. The client should then never subscribe for events from before this point.

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.

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.
   • When the send tracker is closed, the callback will be called immediately with AbortedDueToShutdown.
   • the closing of objects should not synchronize with the completion of the callback via performUnlessClosing unless the synchronized object is responsible for closing the sequencer client itself (possibly transitively). Otherwise shutdown deadlocks are to be expected between the synchronized object and the send tracker or sequencer client. 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, we will check the pending sends and invoke the provided call-backs with the send result (which can be deliver or timeout) before invoking the eventHandler.

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).

The sequencer client computes the cost of submission requests sent to the sequencer, and update the traffic state when receiving confirmation that the event has been sequenced. This is done via the traffic state controller.

TODO(#16601) Make this method private once PerformUnlessClosing doesn't need it any more

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

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 this as a flag to the retry lib or you really know what you're doing, prefer performUnlessClosing and friends.

Set this to true to get detailed information about all futures that did not complete during shutdown.

How often to poll to check that all tasks have completed.

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

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. DO NOT PUT retries, especially indefinite ones, inside f.

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. DO NOT PUT retries, especially indefinite ones, inside f.

Use this method if closing/shutdown of the object should wait for asynchronous computation to finish too.

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. DO NOT PUT retries, especially indefinite ones, inside f.

Use this method if closing/shutdown of the object should wait for asynchronous computation to finish too.

TODO(#16601) Make this method private once PerformUnlessClosing doesn't need it any more

Schedules the given task to be run upon closing.

Register a task to run when closing is initiated, or run it immediately if closing is already ongoing. Unlike runOnClose, this method does not guarantee that this task will have run by the time the LifeCycleManager's closeAsync method completes or AutoCloseable's close returns. This is because the task is run immediately if the component has already been closed.

Variant of runOnOrAfterClose that does not return a com.digitalasset.canton.lifecycle.LifeCycleRegistrationHandle.

Flattened version of sendAsync

Runs the computation fa unless isClosing returns true.

This method does not delay the closing while fa is running, unlike the methods in HasSynchronizeWithClosing. Accordingly, this method is useful for intermittent checks whether the result of the computation is still relevant.