-
Notifications
You must be signed in to change notification settings - Fork 562
Add clientSequenceNumber to the data corruption error where it doesn't advance #26314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add clientSequenceNumber to the data corruption error where it doesn't advance #26314
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR enhances error logging for data corruption detection by adding clientSequenceNumber to the message payload string used in error reports. This additional information will help debug issues where clientSequenceNumbers fail to increase properly for a given client.
Changes:
- Added
clientSequenceNumberfield to thecomparableMessagePayloadmethod output, which is used when logging data corruption errors
|
just a note, but it doesn't seem like this data corruption error use the factories or the extract safe message properties function from telemetry. this could create problems for partners that depend on things like message timestamp to dedupe. |
Chatted offline, the logic is different. That one is about two different ops getting the same sequence number. This one is about a client's single op being sequenced twice (different sequence numbers) |
Good point. I added a factory for DataCorruptionError (shared code with DataProcessingError) and used it here. |
| // Note: It's possible for a duplicate op to be broadcasted and have everything the same except the timestamp. | ||
| private comparableMessagePayload(m: ISequencedDocumentMessage): string { | ||
| return `${m.clientId}-${m.type}-${m.sequenceNumber}-${m.minimumSequenceNumber}-${m.referenceSequenceNumber}-${m.timestamp}`; | ||
| return `${m.clientId}-${m.type}-${m.minimumSequenceNumber}-${m.referenceSequenceNumber}-${m.timestamp}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is reverted back to the state before #26099.


#26099 added a data corruption error "Found two messages with non-increasing clientSequenceNumber for a given client".
The error logs don't include
clientSequenceNumberwhich will be useful in debugging. This PR adds it to the erorr logs for both the messages.Also, added a
createfunction toDataCorruptionErrorsimilar toDataProcessingErrorand used it here which logs important properties from the message that causes the corruption.