Electric.Replication.Changes.Commit (electric v1.4.11)

View Source

Summary

Types

t()

Functions

calculate_final_receive_lag(commit, current_mono)

Calculate the final receive lag in milliseconds.

calculate_initial_receive_lag(commit_timestamp, current_time)

Calculate the initial receive lag in milliseconds, clamped to >= 0.

Types

t()

@type t() :: %Electric.Replication.Changes.Commit{
  commit_timestamp: DateTime.t() | nil,
  initial_receive_lag: non_neg_integer() | nil,
  received_at_mono: integer() | nil,
  transaction_size: non_neg_integer(),
  txn_change_count: non_neg_integer()
}

Functions

calculate_final_receive_lag(commit, current_mono)

@spec calculate_final_receive_lag(t(), integer()) :: non_neg_integer()

Calculate the final receive lag in milliseconds.

Combines the initial receive lag (captured when the commit was received) with the time elapsed within Electric (measured using monotonic time).

Note: If the initial receive lag was clamped to 0 due to clock skew (see calculate_initial_receive_lag/2), the value returned here represents only Electric's internal processing time, not the true end-to-end lag from Postgres commit to acknowledgement.

calculate_initial_receive_lag(commit_timestamp, current_time)

@spec calculate_initial_receive_lag(DateTime.t(), DateTime.t()) :: non_neg_integer()

Calculate the initial receive lag in milliseconds, clamped to >= 0.

This handles clock skew between Postgres and Electric by ensuring the lag is never negative even if the commit timestamp appears to be in the future from Electric's perspective.

Note: When clocks are skewed such that the commit timestamp is ahead of Electric's clock, this function clamps the result to 0. This means information about actual network/replication lag is lost, and the final receive lag reported by calculate_final_receive_lag/2 will only reflect Electric's internal processing time, not the true end-to-end lag from Postgres commit to Electric receipt.