The approximate timestamp

This is either the last observed sequencer timestamp OR the effective timestamp after we observed the time difference of (effective - sequencer = epsilon)

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

Finds the transaction with maximum effective time that has been sequenced before or at sequencedTime and yields the sequenced / effective time of that transaction. Potentially waits for sequencedTime to be observed.

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

If the timestamp is already observed, returns None.

Waits until a snapshot is available

The snapshot returned by this method should be used for validating transaction and reassignment requests (Phase 2 - 7). Use the request timestamp as parameter for this method. Do not use a response or result timestamp, because all validation steps must use the same topology snapshot.

Supervised version of awaitSnapshot

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

If the timestamp is already observed, returns None.

Overloaded recent snapshot returning derived type

The order in which the subscriber should be executed among all the subscriptions. Lower values are executed first.

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 prepare regular transactions using this snapshot, but use the currentSnapshotApproximation instead. A head snapshot can be useful, however, for producing new topology changes, e.g., for picking the correct serial.

Returns the topology information at the timestamp point in time, but using desiredTimestamp as the actual "forwarded" timestamp.

The snapshot returned by this method should ONLY BE USED when computing the timestamp for signature validation (i.e. com.digitalasset.canton.crypto.SyncCryptoClient.getSnapshotForTimestamp).

current number of changes waiting to become effective

This must be called whenever a topology transaction is committed. It may be called at additional timestamps with transactions being empty. Calls must have strictly increasing sequencedTimestamp and effectiveTimestamp.

During crash recovery previous calls of this method may be replayed. Therefore, implementations must be idempotent.

The effective timestamp may have not yet been reached on the synchronizer.

The synchronizer this client applies to

Returns the topology information at a certain point in time

Use this method if you are sure to be synchronized with the topology state updates. The method will block & wait for an update, but emit a warning if it is not available

The snapshot returned by this method should be used for validating transaction and reassignment requests (Phase 2 - 7). Use the request timestamp as parameter for this method. Do not use a response or result timestamp, because all validation steps must use the same topology snapshot.

Returns true if the topology information at the passed timestamp is already known

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 synchronizer parameters.

This is the highest timestamp for which we can serve snapshots

Returns the topology information at a certain point in time

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

The snapshot returned by this method should be used for validating transaction and reassignment requests (Phase 2 - 7). Use the request timestamp as parameter for this method. Do not use a response or result timestamp, because all validation steps must use the same topology snapshot.

Move the highest known (effective / approximate) timestamp ahead in the future.

May only be called if:

1. All committed topology transactions with effective time up to effectiveTimestamp have been persisted in the topology store.
2. All committed topology transactions with sequenced time up to sequencedTimestamp have been persisted in the topology store.
3. sequencedTimestamp <= effectiveTimestamp
4. approximateTimestamp <= effectiveTimestamp
5. A sequenced event with timestamp at least approximateTimestamp has been received from the sequencer.

The effective timestamp may have not yet been reached on the synchronizer.