Don't put reliable timestamps in the unreliable log file header field
James and I debugged a log file sorting bug which turned out to be a
logging bug. The SystemParameters timestamp file (which we can all
agree is a reliable message) had the delivery time in
oldest_unreliable_remote_monotonic_timestamps, which is only for
unreliable timestamps.
This was because reliability was being tracked for the contents channel,
not the source message. Instead, we need to do the book-keeping to
track if the source is realiable or not, and update the header
accordingly. While we don't want to see new combined timestamp logs, we
still need to support them. We don't mind if they are a bit less
efficient to log.
Change-Id: I292f5c0a64926904e13fb5d712acd523f3849cd4
Signed-off-by: Austin Schuh <austin.schuh@bluerivertech.com>
diff --git a/aos/events/logging/log_writer.h b/aos/events/logging/log_writer.h
index 5c8b0c7..6b04f5d 100644
--- a/aos/events/logging/log_writer.h
+++ b/aos/events/logging/log_writer.h
@@ -199,6 +199,17 @@
// If true, this message is being sent over a reliable channel.
bool reliable_forwarding = false;
+
+ // One of the following will be populated. If channel_reliable_contents is
+ // non zero size, it contains a mapping from the event loop channel (not the
+ // logged channel) to a bool telling us if that particular channel is
+ // reliable.
+ //
+ // If channel_reliable_contents is empty, reliable_contents will contain the
+ // same info for all contents logged here. This is the predominant case for
+ // split timestamp channels (the prefered approach).
+ bool reliable_contents = false;
+ std::vector<bool> channel_reliable_contents;
};
// Vector mapping from the channel index from the event loop to the logged