feat: expose consensus timestamp in user properties#64
feat: expose consensus timestamp in user properties#64justynspooner wants to merge 5 commits intotashigit:mainfrom
Conversation
Thread the TCE consensus timestamp (nanosecond precision) through the dispatch chain and include it as a `consensus_timestamp` user property on delivered PUBLISH packets when `include_broker_timestamps` is enabled.
The value is a raw nanosecond Unix epoch, so the property name should make the unit explicit to avoid consumer ambiguity.
When a new subscriber receives retained messages, pass through the original consensus timestamp so that the consensus_timestamp_ns user property is present. Only set when TCE is active, since non-TCE retained timestamps are local system time, not consensus time.
Assert that consensus_timestamp_ns is present and is a valid nanosecond Unix epoch on messages delivered with broker timestamps.
Divyanshu11011
left a comment
Divyanshu11011
left a comment
There was a problem hiding this comment.
Plumbing looks clean : Option<u64> threaded through dispatch → MailSender::deliver → OrderedMail/UnorderedMail/Delivery → txn_to_packet,
with Some(consensus_timestamp) only from handle_tce_event. Retained replay correctly reuses the consensus timestamp used as the retain index key. Both
txn_to_packet call sites in connection.rs are updated.
One coupling concern: without #65, the "known limitation" you documented means clients see consensus_timestamp_ns on messages from remote publishers but
never on their own publishes : a silently inconsistent semantic that's hard for clients to reason about. Strongly recommend landing this with or after #65, not before.
Nit: a Rust unit test on txn_to_packet with Some(consensus_timestamp) would lock in the property name and encoding without needing the TCE stack.
2 participants
Warning
Proof of concept — this was authored with the assistance of Claude 4.6 (Opus) and has not been compiled or tested as I don't have SSH access to the private
tashi-consensus-enginedependency.rustfmtpasses butcargo check/clippycould not be run. Please review with that in mind.Summary
consensus_timestamp_nsas a user property on delivered PUBLISH packets wheninclude_broker_timestampsis enabledNone, so the property is omittedconsensus-timestamps.test.jsto assertconsensus_timestamp_nsis present and validKnown limitation
consensus_timestamp_nsset. Only messages arriving through the TCE event handler include it. This is a pre-existing design tradeoff (latency vs consistency) and should be addressed in a separate PR.Test plan
consensus_timestamp_nsuser property appears on messages delivered via TCEconsensus_timestamp_nsis absent for locally dispatched messages (no TCE)consensus_timestamp_nsconsensus-timestamps.test.jsintegration test