pub struct Completion1 {
pub command_id: String,
pub status: Option<Box<JsStatus>>,
pub update_id: Option<String>,
pub user_id: String,
pub act_as: Vec<String>,
pub submission_id: Option<String>,
pub deduplication_period: Option<Box<DeduplicationPeriod1>>,
pub trace_context: Option<Box<TraceContext>>,
pub offset: i64,
pub synchronizer_time: Box<SynchronizerTime>,
pub paid_traffic_cost: Option<i64>,
}Expand description
Completion1 : A completion represents the status of a submitted command on the ledger: it can be successful or failed.
Fields§
§command_id: StringThe ID of the succeeded or failed command. Must be a valid LedgerString (as described in value.proto). Required
status: Option<Box<JsStatus>>§update_id: Option<String>The update_id of the transaction or reassignment that resulted from the command with command_id. Only set for successfully executed commands. Must be a valid LedgerString (as described in value.proto). Optional
user_id: StringThe user-id that was used for the submission, as described in commands.proto. Must be a valid UserIdString (as described in value.proto). Required
act_as: Vec<String>The set of parties on whose behalf the commands were executed. Contains the act_as parties from commands.proto filtered to the requesting parties in CompletionStreamRequest. The order of the parties need not be the same as in the submission. Each element must be a valid PartyIdString (as described in value.proto). Required: must be non-empty
submission_id: Option<String>The submission ID this completion refers to, as described in commands.proto. Must be a valid LedgerString (as described in value.proto). Optional
deduplication_period: Option<Box<DeduplicationPeriod1>>§trace_context: Option<Box<TraceContext>>§offset: i64May be used in a subsequent CompletionStreamRequest to resume the consumption of this stream at a later time. Must be a valid absolute offset (positive integer). Required
synchronizer_time: Box<SynchronizerTime>§paid_traffic_cost: Option<i64>The traffic cost paid by this participant node for the confirmation request for the submitted command. Commands whose execution is rejected before their corresponding confirmation request is ordered by the synchronizer will report a paid traffic cost of zero. If a confirmation request is ordered for a command, but the request fails (e.g., due to contention with a concurrent contract archival), the traffic cost is paid and reported on the failed completion for the request. If you want to correlate the traffic cost of a successful completion with the transaction that resulted from the command, you can use the offset field to retrieve the transaction using UpdateService.GetUpdateByOffset on the same participant node; or alternatively use the update_id field to retrieve the transaction using UpdateService.GetUpdateById on any participant node that sees the transaction. Note: for completions processed before the participant started serving traffic cost on the Ledger API, this field will be set to zero. Additionally, the total cost incurred by the submitting node for the submission of the transaction may be greater than the reported cost, for example if retries were issued due to failed submissions to the synchronizer. The cost reported here is the one paid for ordering the confirmation request. Optional
Implementations§
Source§impl Completion1
impl Completion1
Sourcepub fn new(
command_id: String,
user_id: String,
act_as: Vec<String>,
offset: i64,
synchronizer_time: SynchronizerTime,
) -> Completion1
pub fn new( command_id: String, user_id: String, act_as: Vec<String>, offset: i64, synchronizer_time: SynchronizerTime, ) -> Completion1
A completion represents the status of a submitted command on the ledger: it can be successful or failed.
Trait Implementations§
Source§impl Clone for Completion1
impl Clone for Completion1
Source§fn clone(&self) -> Completion1
fn clone(&self) -> Completion1
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more