Allows a member to acknowledge that they have read all events up to and including the provided timestamp, and that they will never re-read these events again. This information is currently only used for informational purposes and to provide a watermark for which it is safe to prune earlier events from the sequencer data stores. There is no requirement for every event to be individually acknowledged, and in fact callers are encouraged to only periodically record acknowledgements (at an interval of minutes is expected to be more than sufficient for pruning).

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.

Download the topology state for a member up to including the topology transaction that made the member known on the synchronizer.

Return the currently known traffic state for a member. Callers must be authorized to request the traffic state.

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.

Submit a request to the sequencer.

A request contains a batch, which is a sequence of envelopes. Every envelope consists of its content and a set of recipients, arranged in a forest. A synchronizer member is intended to receive those envelopes of a batch that contain the member as a recipient. A synchronizer member is supposed to learn about those recipients of an envelope that are (1) specified at a node that also specifies the member or (2) at a descendant thereof. (I.e., a node further down in the recipient forest.)

The sequencer may or may not accept a request. If an incoming request is valid (i.e., it can be parsed and every field meets its documented validity conditions) an honest sequencer will accept requests in a best effort manner, provided resource limits are met.

For every accepted request, the sequencer assigns a unique sequencing timestamp to the request. All honest sequencers of the synchronizer will deliver an event to the sender and to those synchronizer members that are intended to receive at least one envelope.

Honest sequencers may deliver to all sequencers of the synchronizer events that don't correspond to submitted requests. Sequencer implementations may leverage this mechanism for internal purposes.

An event for a synchronizer member contains only those envelopes of the batch of the request that the member is intended to receive and the recipients of an envelope contains only those that the member is supposed to learn about. A member will receive the envelopes of the same request within a single event. A member will receive events ordered by sequencing timestamp.

If a request is accepted, the sender will receive a corresponding event, called "receipt"; so that the sender is informed that the sequencer has accepted the request. If the sender is not a recipient of the request, the receipt has an empty batch.

If the request contains an aggregation rule, the sequencer will process requests in an aggregated fashion. A set of requests belong to the same aggregation, if they have essentially the same contents (details specified at SubmissionRequest.aggregationId). The sequencer validates and assigns sequencing timestamps to requests within an aggregation just as for requests without an aggregation rule. The sequencer emits events and receipts for an accepted request within an aggregation as follows: - As long as the number of accepted requests is strictly less than AggregationRule.threshold, the sequencer only emits a receipt with an empty batch to the sender of the request. It does not emit any other events. - As soon as the number of accepted requests equals AggregationRule.threshold, the sequencer emits events to the sender and the recipients of the request. The sequencing timestamp of the events is the sequencing timestamp of the last accepted request. - The sequencer will not accept more than AggregationRule.threshold requests. The sequencer will reject any further request that could otherwise be accepted. Consequently, events for the request are delivered only once even if the threshold is attained multiple times.

If the request does not contain an aggregation rule, even honest sequencers may deliver events for the request more than once (with different sequencing timestamps), as malicious sequencers may replay a request internally. Clients need to implement appropriate deduplication, if at-most-once delivery is needed. Once request.max_sequencing_time has elapsed (i.e. an event with an equal or higher timestamp has been emitted), an honest sequencer will not emit events corresponding to request anymore.

The sequencer may reject a request, e.g., because the request is invalid or the sequencer is overloaded. The sequencer will indicate a rejection (independently of whether there is an aggregation rule) in exactly one of the following ways: (1) synchronously, by returning an error in the response of this method (2) asynchronously, by emitting an error in the response to SubscribeVersioned to the sender and possibly an empty batch to non-sender recipients (3) by not emitting a receipt to the sender until request.max_sequencing_time Note that only (2) and (3) can be trusted. A malicious sequencer may synchronously return an error and still accept the request internally and therefore emit events later on.

Establishes a stream with the server to receive sequenced events from the synchronizer after the given counter. The delivered events will have a reference to the previous event (its timestamp) and a strictly monotonically increasing timestamp.

The call fails synchronously, if the request is invalid, i.e., some field violates a documented validity condition. The call fails asynchronously, if the sequencer does not have a key to sign the event; this may occur if event.topology_timestamp refers to a time before the sequencer has been onboarded.

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.