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

Enable most writer conformance tests for Rust #1313

Open
wants to merge 22 commits into
base: main
Choose a base branch
from
Open

Conversation

Muon
Copy link

@Muon Muon commented Jan 17, 2025

Changelog

The DataEnd CRC calculation and missing writer options have been added to allow the Rust writer to pass the conformance tests.

Docs

https://linear.app/foxglove/issue/FG-9567/rust-mcap-writer-doesnt-pass-or-run-conformance-tests

Description

Previously, the Rust writer could not pass the conformance tests because it was not possible to control which summary record types would be included and because it would not compute the CRC for the DataEnd record.

Now, all current writer conformance tests pass, except the ones using the "pad" option. This brings the Rust crate up to parity with the C++ library (and possibly others).

BeforeAfter

No writer conformance tests run or pass

All writer conformance tests except those with "pad" pass

Fixes: FG-9567

Copy link

linear bot commented Jan 17, 2025

schemas: Default::default(),
channels: Default::default(),
next_channel_id: 0,
next_channel_id: 1,
Copy link
Collaborator

Choose a reason for hiding this comment

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

why is this change neccessary?

Copy link
Author

Choose a reason for hiding this comment

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

Good question. I was going to say something about the other writers starting from 1, but they don't. Actually, it's because the Rust interface tries to be clever and doesn't let you pick your own channel IDs, but the tests start from 1. If the tests started from a different number things would break.

Changing add_channel() to let you pick your own would be a breaking change. Or we could add a new method?

Copy link
Collaborator

Choose a reason for hiding this comment

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

You can choose your own channel IDs if you call write(Message{}) and set the channel ID in the Message.channel.id field.

Copy link
Author

@Muon Muon Jan 17, 2025

Choose a reason for hiding this comment

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

The problem is not writing the Message record, but the Channel record. We can't currently choose the ID when creating a Channel, and Channels may be created even if there are no messages.

Copy link
Collaborator

Choose a reason for hiding this comment

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

you don't need to call add_channel before calling Write(Message{channel: Some(Channel{...})). This will write the channel record with the ID you specify, then the message record.

Copy link
Collaborator

Choose a reason for hiding this comment

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

You can avoid writing a channel record when you see a Channel object in the spec JSON, instead storing it in a map somewhere. Then you call Write(Message) when the message comes up in the spec.

@@ -672,7 +793,7 @@ impl<W: Write + Seek> Writer<W> {
const WHERE_WRITER: &'static str = "Trying to write a record on a finished MCAP";

/// Starts a new chunk if we haven't done so already.
fn chunkin_time(&mut self) -> McapResult<&mut ChunkWriter<W>> {
fn start_chunk(&mut self) -> McapResult<&mut ChunkWriter<W>> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

🥹

Copy link
Author

Choose a reason for hiding this comment

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

I am a killjoy who prioritizes code readability.

Copy link
Contributor

Choose a reason for hiding this comment

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

I felt the itch to remove but ultimately felt the love when I saw this last time 🥹. Had to be done though.

@@ -175,6 +205,87 @@ impl WriteOptions {
self
}

/// Specifies whether the writer should output statistics automatically.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't understand the use of "automatically" - there's not a manual alternative. Maybe:

Suggested change
/// Specifies whether the writer should output statistics automatically.
/// Specifies whether the writer should output a statistics record in the summary section.

self
}

/// Specifies whether the writer should output a summary record automatically.
Copy link
Collaborator

Choose a reason for hiding this comment

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

There is no summary record, there is a summary section (the records between the data end record and the footer record) which may be empty. https://mcap.dev/spec#summary-section

self
}

/// Specifies whether the writer should output summary offsets automatically.
Copy link
Collaborator

Choose a reason for hiding this comment

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

The use of "automatically" here and throughout confuses me. the caller is not choosing between automatic and manual, they're choosing between present and absent.

Copy link
Collaborator

@james-rms james-rms left a comment

Choose a reason for hiding this comment

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

The new write option docstrings need updates, but the other changes look good.

@Muon
Copy link
Author

Muon commented Jan 17, 2025

I'll fix up the docstrings.

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.

3 participants