Skip to content
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

Fix time range being incorrectly reported to start at 0 #6

Merged

Conversation

achim-k
Copy link
Contributor

@achim-k achim-k commented Nov 15, 2024

Changelog

Fix time range being incorrectly reported to start at 0

Docs

None

Description

Fixes that the time range being incorrectly reported to start at 0 by using only data & log messages for determining the time range.

Copy link

linear bot commented Nov 15, 2024

@achim-k achim-k requested a review from jtbandes November 15, 2024 17:08
src/ULog.ts Outdated
Comment on lines 251 to 254
// Other message types do not have a timestamp field, so we use the current max. timestamp or
// alternatively the header timestamp which denotes when the logging started.
const timestamp = maxTimestamp ?? this._header.timestamp;
timeIndex.push([timestamp, i++, message]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do messages without a timestamp field need to be in the timeIndex?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was wondering the same. The reason is, that the current readMessages generator function returns all messages in the data section. If we limit this to only return message types with timestamps, then we do not have to add messages without a timestamp to the time index.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these other message types that don't have timestamps used for anything? Seems like we could either not emit them from readMessages or skip them when building the index?

Copy link
Contributor Author

@achim-k achim-k Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these other message types that don't have timestamps used for anything?

At least not by us. Not sure if there are any other users of this package (other than Lichtblick).
I think I will go ahead and not emit these kind of messages.

Edit: I kept the types of emitted messages the same and only changed the time range calculation

@achim-k achim-k requested a review from jtbandes November 18, 2024 22:32
src/ULog.test.ts Outdated
@@ -301,7 +301,7 @@ describe("README.md", () => {
const ulog = new ULog(reader);
await ulog.open(); // required before any other operations
expect(ulog.messageCount()).toBe(64599); // ex: 64599
expect(ulog.timeRange()).toEqual([0n, 181493506n]); // ex: [ 0n, 181493506n ]
expect(ulog.timeRange()).toEqual([112574307n, 181493506n]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

magical - we already had a (broken) test case 🎉

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, turned out that there is really a data message with 0n timestamp. Change here was related to the minTimestamp assignment bug

src/ULog.ts Outdated
let maxTimestamp = 0n;
let logMessageCount = 0;

let i = 0;
let message: DataSectionMessage | undefined;
while ((message = await this.readParsedMessage())) {
if (message.type === MessageType.Data) {
minTimestamp ??= message.value.timestamp;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are never checking with <, how do we know this is the min?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arg, good catch! I forgot that these messages are not necessarily ordered

@achim-k achim-k requested a review from jtbandes November 19, 2024 01:38
@achim-k achim-k merged commit 3e0ee44 into main Nov 19, 2024
1 check passed
@achim-k achim-k deleted the achim/fg-9416-ulog-incorrect-handling-of-addlogged-timestamp-0 branch November 19, 2024 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants