Deletes the referred to in-flight submissions if there are any.

If the com.digitalasset.canton.sequencing.protocol.MessageId in com.digitalasset.canton.participant.store.InFlightSubmissionStore.InFlightByMessageId is not a UUID, there cannot be a matching in-flight submission because register forces a UUID for the message ID.

Returns all sequenced in-flight submissions on the given domain whose com.digitalasset.canton.participant.protocol.submission.SequencedSubmission.sequencingTime is no later than sequencingTimeInclusive.

The in-flight submissions are not returned in any specific order.

Returns all unsequenced in-flight submissions on the given domain whose com.digitalasset.canton.participant.protocol.submission.UnsequencedSubmission.timeout is no later than observedSequencingTime.

The in-flight submissions are not returned in any specific order.

Moves the submission with the given com.digitalasset.canton.protocol.RootHash from com.digitalasset.canton.participant.protocol.submission.UnsequencedSubmission to com.digitalasset.canton.participant.protocol.submission.SequencedSubmission.

If a com.digitalasset.canton.participant.protocol.submission.SequencedSubmission with the given com.digitalasset.canton.protocol.RootHash already exists:

• if the given submission was sequenced earlier than the existing one, it replaces it;
• otherwise, this call will be ignored.

As this method is called from the asynchronous part of message processing, this behavior ensures that the in-flight submission tracker always ends up tracking the earliest request for a given com.digitalasset.canton.protocol.RootHash, independently of the order in which these calls are made, in accordance with the replay prevention mechanism.

If the later request writes first, the InFlightSubmissionStore contains stale data for the submission request until the earlier request updates the row. This is fine because the stale information will only be read by the com.digitalasset.canton.participant.protocol.submission.InFlightSubmissionTracker after the corresponding completion event has been published by the com.digitalasset.canton.participant.event.RecordOrderPublisher. However, this happens only after the earlier request has signalled its tick, i.e., when Phase 3 has finished (via the com.digitalasset.canton.participant.protocol.Phase37Synchronizer and either a com.digitalasset.canton.protocol.messages.MediatorResult has been processed or the decision time has elapsed. By this time, the row with the stale data has been overwritten by the earlier request.

Calls to this method also race with calls to observeSequencing for later messages, e.g., if a submission request gets preplayed without a message ID. The argument about the stale data being benign also applies to those races. There are no races between several calls to observeSequencing because observeSequencing is called sequentially for each batch of sequenced events.

Registers the given submission as being in flight and unsequenced unless there already is an in-flight submission for the same change ID.

This method MUST NOT run concurrently with a delete query for the same change ID and message ID. When this method fails with an exception, it is unknown whether the submission was registered.

Updates the registration of the given unsequenced submission with its root hash information.

If the root hash for the given submission has already been set by a previous call to this method, the new update will be ignored. If the given submission is not found in the store, the update will be ignored. We don't report an error because it can happen e.g. if the max sequencing time has already elapsed and the timely rejection published.

This is done as a separate operation from register because the root hash is currently not known at registration time.

Update the in-flight submission identified by the given changeId if submissionDomain and messageId match and it is unsequenced and the existing com.digitalasset.canton.participant.protocol.submission.UnsequencedSubmission.timeout is not earlier than the newSequencingInfo's com.digitalasset.canton.participant.protocol.submission.UnsequencedSubmission.timeout. Only the field com.digitalasset.canton.participant.protocol.submission.InFlightSubmission.sequencingInfo is updated.

This is useful to change when and how a rejection is reported, e.g., if the submission logic decided to not send the com.digitalasset.canton.sequencing.protocol.SubmissionRequest to the sequencer after all.