Wait for a condition to become true according to the current snapshot approximation

Overloaded recent snapshot returning derived type

The domain this client applies to

Returns the topology information at a certain point in time

Fails with an exception if the state is not yet known.

returns the current approximate timestamp

whenever we get an update, we do set the approximate timestamp first to the sequencer time and schedule an update on the clock to advance the approximate time to the effective time after the time difference elapsed.

Waits until a snapshot is available

Supervised version of awaitSnapshot

Shutdown safe version of await snapshot

Supervised version of awaitSnapshotUS

Returns an optional future which will complete when the timestamp has been observed

If the timestamp is already observed, we return None.

Note that this function allows to wait for effective time (true) and sequenced time (false). If we wait for effective time, we wait until the topology snapshot for that given point in time is known. As we future date topology transactions (to avoid bottlenecks), this might be before we actually observed a sequencing timestamp.

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

Possibly future dated head snapshot

As we future date topology transactions, the head snapshot is our latest knowledge of the topology state, but as it can be still future dated, we need to be careful when actually using it: the state might not yet be active, as the topology transactions are future dated. Therefore, do not act towards the sequencer using this snapshot, but use the currentSnapshotApproximation instead.

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.

current number of changes waiting to become effective

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 that will run onClose after all "performUnlessShutdown" tasks have finished

Overloaded snapshot returning derived type

Returns whether a snapshot for the given timestamp is available.

The most recently observed effective timestamp

The effective timestamp is sequencer_time + epsilon(sequencer_time), where epsilon is given by the topology change delay time, defined using the domain parameters.

This is the highest timestamp for which we can serve snapshots

Move the most known timestamp ahead in future based of newly discovered information

We don't know the most recent timestamp directly. However, we can guess it from two sources: What was the timestamp of the latest topology transaction added? And what was the last processing timestamp. We need to know both such that we can always deliver the latest valid set of topology information, and don't use old snapshots. Therefore, we expose the updateHead function on the public interface for initialisation purposes.