Keep track of the RRD protocol version and display it where relevant #6324
Conversation
teh-cmc
added
enhancement
| let StoreInfo { | ||
| application_id, | ||
| recording_id, | ||
| store_source, | ||
| store_version, | ||
| rust_version, | ||
| llvm_version, | ||
| python_version, | ||
| is_official_example, | ||
| app_id_starts_with_rerun_example, | ||
| } = store_info; |
There was a problem hiding this comment.
Got bitten by the lack of de-structuring here
|
@rerun-bot full-check |
|
Started a full build: https://github.com/rerun-io/rerun/actions/runs/9082568457 |
| @@ -361,6 +363,13 @@ pub struct StoreInfo { | |||
| pub started: Time, | |||
|
|
|||
| pub store_source: StoreSource, | |||
|
|
|||
| /// The Rerun version used to encoded the RRD data. | |||
There was a problem hiding this comment.
I think we might need to be more specific here by what we mean when we say "encoding".
There is both the outer-encoding of the RRD framing, and the inner-encoding of the arrow schemas.
As implemented this is the Rerun version used to TRANSMIT the encoded data.
If you for example:
- Create an RRD with 0.15
- Load the RRD into an 0.16 viewer
- Re-save the RRD trough the viewer
You will end up with 0.16 in the stream, that still has 0.15-encoded payloads.
I actually think we would be better off tracking this explicitly all the way through so that this version can be used as a concise proxy for the encoded arrow schemas as well.
There was a problem hiding this comment.
Regarding the two layers of framing, I think we're better off considering they are always one and the same until we really push for stabilization of our protocol. It keeps things simple.
The fact that re-saving the data overrides the original version seems like a bug, it should re-use the original version. I should fix that.
(Also I'm realizing that it is possible to indefinitely append data to an existing recording using a different version of the SDK each time, is not? In which case all of this really is best effort anyhow, unless we want to keep track of a set of versions?!)
There was a problem hiding this comment.
I think we're better off considering they are always one and the same until we really push for stabilization of our protocol. It keeps things simple.
Awesome. This makes sense to me.
There was a problem hiding this comment.
I made it so that the Encoder now requires a CrateVersion to be explicitly stated.
When saving from the viewer, that version is now picked up from the existing StoreInfo in the EntityDb (if any).
Seems to work fine for the things I've tested, though I'm sure there are crazy edge cases lurking somewhere... Rerun versioning is hard 🤪
|
@rerun-bot full-check |
|
Started a full build: https://github.com/rerun-io/rerun/actions/runs/9083847171 |
This augments
StoreInfowith an in-memory only (!)store_versionfield.Our
DecoderandStreamDecoderhave been patched to fill out this field using the RRD version present in the stream's header.This version is now visible in the UI, using the CLI, and in the analytics.
Viewer:
CLI:
Analytics:
Checklist
mainbuild: rerun.io/viewernightlybuild: rerun.io/viewerTo run all checks from
main, comment on the PR with@rerun-bot full-check.