[C++ repro] Logging lots of image looses data

[abey79]

User-provided C++ repro highlight loss of logged data.

Expected: all data is logged, 50 frames on the timeline
Actual: partial data, only ~33 frames

Repro repo: https://github.com/ExpertOfNil/rerun_cpp_mve
Discord thread: https://discord.com/channels/1062300748202921994/1364955449602084874
Slack thread: https://rerunio.slack.com/archives/C041NHU952S/p1745826038111429

[abey79]

Adding a rec.flush_blocking() at the end does NOT fix the issue.

Adding while (true) {} does "fix" the issue (this might be indicative of a possible short-term workaround).

[ExpertOfNil]

Just a point of clarification, in case it is helpful: each image should be logged 4 times (representing the actual application logging various permutations), 3 prior to rr_log_pose_estimation and once more within rr_log_pose_estimation. The end result should be 200 logged images, 50 under mve/original, 50 under mve/Image1, 50 under mve/Image2, and 50 under mve/image along with a pinhole and transform. Let me know if this is not accurately represented in my repro. Otherwise, I'll update the notes to add these details.

[abey79]

This is what I'm getting with the while (true) {} trick. I'm assuming that this is the "expected" state

[ExpertOfNil]

That looks correct! I'm assuming you used while (true) {} in main.cpp to keep the process alive?

[abey79]

That looks correct! I'm assuming you used while (true) {} in main.cpp to keep the process alive?

Yes, exactly.

[ExpertOfNil]

I was able to reproduce completion of all logs with while (true) {}. I also killed the process after pose 40, which seemed to drop the remainder of logs.

Would it be reasonable to provide a mechanism for flushing the RecordingStream, or checking if it has been full flushed, prior to shutting down the main process?

[abey79]

Would it be reasonable to provide a mechanism for flushing the RecordingStream, or checking if it has been full flushed, prior to shutting down the main process?

Well, it was very much my expectation that rec.flush_blocking() would do exactly that, but it's apparently not the case, so may well be a bug. @grtlr is currently looking into all of this and will revert as soon as we figure that out.

[grtlr]

Thank you so much @ExpertOfNil 🙏! Your repro pointed out a very subtle difference in our C++ SDK and made us realized that our logging level was wrong.

For the 0.23.2 release we will create a patch to warn on dataloss. We will properly address the underlying cause for this issue in the 0.24 release (it will probably lead to subtle changes to the API).

You can follow along with that line of development here:

• Change flush_blocking to make flush timeout optional #9845

Until we have the full fix, I would suggest bumping up the flush_timeout_sec parameter in your connect_grpc call to a value that prevents dataloss.