Proto commits in rerun-io/rerun

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-07-07

Add asset datasets, which can be used to store shared data between segments in a dataset. ### Related - Closes RR-4761 ### What Adds a asset dataset, which similar to blueprint datasets are auto********ally created for datasets and have their lifetime tied to the owning dataset. This PR does not do any of the planned filtering with properties, or any client handling of asset layers. ### Testing There are two new `re_redap_tests` which tests registering & getting assets and another that makes sure asset dataset is removed when the dataset is removed. Also adds python e2e_redap_tests. ### Compatibility This deletes an experimental field from a message, which was documented as possibly being removed at any time. --------- Source-Ref: b858c1b4949775dea73f46994619cd1accf8b317 Co-authored-by: Antoine Beyeler <49431240+abey79@users.noreply.github.com>

The documentation is generated from this commit.

2026-07-01

Add `rerun viewer-mcp` ### Related * part of https://linear.app/rerun/project/rerun-mcp-ee806820f51a * needs https://github.com/rerun-io/reality/pull/2286 ### What Adds `rerun mcp`, a mcp server that lets agents interact with a running viewer. ### Testing Tested headfully and headlessly on macos. --------- Source-Ref: 9c0200acf6e7b29cdad2fded01674308bcb2b3b7 Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Jochen Görtler <me@jgoertler.com>

2026-06-26

Split redap_manifest_registry read and write paths to separate services patchset 5 Merge writer and querier proto into single file. Rename proto definitions, structs, fields, functions to have - `ManifestWriter*`, `manifest_writer_*`, `mw(_*)`, - `ManifestQuerier`, `manifest_querier_*`, `mq(_*)` naming scheme. Note that the configuration options and deployments are **not** affected and shall be refactored later when doing the deployment split. Source-Ref: 9d385a9c631acfa057d31c723a9ba9dffe8bcf14

2026-06-16

Implement `WatchEvents` in `re_server` ### Related * Closes RR-4836 * Follow up: RR-4853 * Follow up: RR-4854 * Follow up: RR-4874 ### What This introduces a new `WatchEvent` gRPC call to the Catalog API, which can be used to notify connected viewers about catalog lifecycle changes. This PR is only a first step and introduces entry-based events, so no registering of events (RR-4853). It also does not aim to improve the UI around connection problems (RR-4854). ### Compatibility For now the Hub returns `Unimplemented`, which the viewer handles gracefully. ### Testing * Adds a basic OSS-only test to `re_redap_test`, which tests both new events. Source-Ref: b500ae48ec3afb00c2bc4e2ddcbdd0a40334b890

2026-06-12

Table blueprint registration for segment tables Source-Ref: c65cb14da4ef1f59e2b689bd5cffa5d78f6081c3 Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>

2026-06-11

chore: update lance, datafusion, and arrow ### Related This is a dependency update. ### What - Update Arrow to v58 - Update Lance to v7 - Update DataFusion to v53 ### Testing Existing unit tests ### Compatibility This does require dataframe users to update to `datafusion-python 53.0.0` or later. --------- Source-Ref: 73cd591f48ba8ae9f3fc08456a4e1b4343c6bb60 Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

2026-06-09

feature-removal: drop custom indices Why: - We don't offer them to our customers - They materialize customer data into our manifest registry which - Does not scale - Is a concern for our security / privacy model Where: Remove all traces from * Redap (protocol) * OSS Server * SDK * Hub * Related tests --------- Signed-off-by: Andrea Reale <andrea@rerun.io> Source-Ref: 12746f267765ded03b12504f20893cdee20ca7ab Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Andrea Reale <andrea-reale@users.noreply.github.com>

2026-06-05

Table blueprint registration instead of base64 encoded table blueprints ### Related * Fixes RR-4512 ### What This replaces the base64 inline table blueprint with catalog-backed table blueprint registration, near identical to how we do it with datasets. We had the inline blueprint as purely experimental feature in 0.33 & 0.32, I don't think there's much value in keeping them alive. The Python API exposes experimental helpers to register, list, and select table blueprints for a table. Blueprint registration for both datasets & tables comes with some simple validation now server sided. Table blueprint themselves are tested using existing tests, new registration etc. is tested via the usual e2e server testing. Source-Ref: c72395c90af1df7208383a204119704c52c0d687

2026-06-04

Add experimental support for Asset Layers ### Related * Closes RR-4755 ### What This implements an experimental Python API and re_server implementation of Asset Layers Source-Ref: 6167bfb094f644db2e30b9ab4ab0740a4274050e

2026-06-03

Add experimental `LayerClass` to gRPC protocol ### Related * Part of RR-4755 ### What * Adds experimental gRPC protocol * Refactors `re_server` slightly * Returns "not implemented" on re_server and hub ### Nomenclature <img width="887" height="579" alt="image" src="https://github.com/user-attachments/assets/e53b2af6-2852-41c8-9721-5f574fa8b51c" /> --------- Source-Ref: 8144932fb7cd5ec0c0dfebc351bd965467b81b1b Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

2026-06-01

Lint `.proto` files Bonus: also lint `.mjs` and `.ts` files Source-Ref: f163a9807d86926dd8de2e960bbc761beacb93c9

2026-05-26

dataplatform api: use entry headers everywhere ### Related - RR-4726 - RR-4727 ### What `x-rerun-entry-id` is an existing dataplatform API header using to specify the target of an operation. Using an header instead of the body has a few advantages: - can be interecepted by grpc middlware for telemetry - we can potentially route/aut requests based on the header without necessarily decoding the body The header however was not used uniformly everywhere and many methods were still specifying the target of the request via the body. The main current drawback for that is that we would miss the standard grpc telemetry for `dataset_id`. Notably, I realized this when looking at deletemetry for `delete_entry`. ### What Add header-based target spec to all "eligible" `rerun.cloud` enpoints. Send the header from the clients. * Keep falling back to body to allow old clients to work with new servers * Keep sending id in the body to allow new clients to work with old servers ### Side quest * `with_entry_id` and family used to return a `Result` that would only fire if `EntryId.to_string()` produced non ASCII strings, which it doesn't. Because we use this method /everywhere/, I switch to an `expect` at the call site, which removes lots of boilerplate. ### Compatibility Full forward and backward. --------- Signed-off-by: Andrea Reale <andrea@rerun.io> Source-Ref: 8516ba8433373925bfe0e2f3e2663f3c1aace6e9

2026-05-06

RR-4549: detect metadata-source drift via ETags ### Related * Closes RR-4549 ### Why Customer trace surfaced opaque "Internal" decode failures on `/FetchChunks` which are highly likely to be occurring because the source RRD object had been mutated since registration. However, there was no way for a user (or oncall) to tell drift from genuine corruption, and no actionable error message. This PR makes drift visible end-to-end, and threads diagnostic context through the decode path. ### How * At registration time, the object-store exposed `ETag` and `registration_time` are stored (very redundantly) in the `ChunkKey` column in the partition manifest * This is very redundant, but future/upcoming compression should help a lot. * On `QueryDataset` ChunkKeys are returned to the client (no changes compared to today). * On `/FetchChunks` requests the client sends `ChunkKeys` to the server (no changes) * Chunk scanner uses the new information to evaluate drift (this is new!). * On direct-from-s3, the client now decodes `ChunkKeys` to get etag/registration time info and detect drift **Proto / wire format** * In order to have the SDK decode `ChunkKey` content, this PR promotes `ChunkKey` and `RrdChunkLocation` to the public proto. * As a bonus, because of that, SDK starts to use the offsets in the `ChunkKey` rather than the previously redundantly sent offsets. * Unfortunately, we need to keep sending those back for backwards compatibility. * We'll have to clean them up in the near future when no client still expects them. ** If-Match ** * When we have a strong ETag, we add it as an `If-Then` header to the HTTP request so that the server gives us a precondition failed rather than returning data we know will fail. **ETag quirks** * When the server sends us a strong etag, we use `If-Match` header on the range request to avoid transferring data if we know there's drift * Otherwise, we fallback to post-hoc comparison and only do e-tag matching on decode errors. ### Compatibility **Wire-format** | | Old client | New client | |---|---|---| | **Old server** | as today | sees null `chunk_key.etag` / `registration_time_nanos`, skips `If-Match`, behaves as today | | **New server** | new server still emits the legacy flat columns (`chunk_byte_offset`, `chunk_byte_len`, `rerun_layer_direct_url`); old client ignores the new fields and behaves as today | full enforcement | Runtime deploy is order-independent. **Manifest data** - Legacy partition manifests (registered before this PR) have `ChunkKey.etag` and `ChunkKey.registration_time_nanos` unset. New consumers (server `FetchChunks` and direct-fetch client) treat the absence as "no enforcement" — the precondition path is skipped and behavior matches today. --------- Signed-off-by: Andrea Reale <andrea@rerun.io> Source-Ref: 76a2bd8151a71661abd068895abee0a542ca0951 Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: Andrea Reale <andrea-reale@users.noreply.github.com>

Push down per-segment using index values to server ### Related * Closes RR-4355 * Closes https://github.com/rerun-io/reality/pull/1572 ### What Switch from pulling all chunks for a segment when we have `using_index_values` to allowing the user to specify the mapping from segment ID to index values. This pushes the logic down to the server about which chunks are relevant for the query, and should lead to significant performance enhancements when we have many different index values / segment ID combinations. ### Testing Additional tests included. ### Compatibility This is backwards compatible, so new clients will still work with older servers. --------- Source-Ref: c593a0ecd20a7c8df94377fb30e37d1ad32470ae Co-authored-by: Andrea Reale <andrea@rerun.io> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com> Co-authored-by: mailmindlin <mailmindlin@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

2026-04-30

`CatalogClient`: Add RTT and bandwidth probes ## Summary - Adds server-streaming RPC `RerunCloudService.DoBandwidthTest(num_bytes) -> stream { payload: bytes }` for measuring round-trip time and bandwidth between a client and the cloud. - The server returns exactly `num_bytes` of pseudo-random, incompressible bytes (xorshift64*), split into ~1 MiB chunks. The payload generator lives in `re_protos::cloud::v1alpha1::ext::BandwidthTestPayloadIter` and is shared by `re_server` (local/test) and `redap_frontend` (production cloud). - Exposes a single high-level Python helper on `CatalogClient`: ```python client = rr.catalog.CatalogClient("…") print(client.benchmark()) # BenchmarkResult(rtt=12.0 ms, bandwidth=112.0 MiB/s) ``` `benchmark()` returns a frozen `BenchmarkResult` dataclass (`rtt: timedelta`, `bandwidth: float | None`); all formatting lives in `__repr__`. The grpc-matching low-level methods (`rtt_seconds`, `bandwidth_bytes_per_sec`) stay on `CatalogClientInternal` for callers who want raw numbers. ## How it works 1. RTT is the **minimum** elapsed time across `num_pings` (default 5) calls to `/DoBandwidthTest` with `num_bytes = 1`. Using the minimum (not the mean) rejects latency spikes from scheduling jitter or transient network congestion. 2. Bandwidth is `num_bytes / (elapsed - rtt)` after a single `/DoBandwidthTest` request. `bandwidth` is `None` (rendered as `"(too fast to measure)"`) when `elapsed ≤ rtt` — e.g. a small payload on a fast loopback connection where transfer time is dominated by RTT. ## Why incompressible bytes gRPC and proxies may transparently compress payloads. An xorshift64\* stream is high-entropy, so any general-purpose codec leaves it untouched — we measure raw transport bandwidth, not a compression ratio. ## Test plan - [x] `cargo clippy -D warnings` clean for `re_protos`, `re_server`, `redap_frontend`, `re_redap_client`, and `rerun_py`. - [x] Python wheel rebuild, `python_check_signatures.py` and `py-fmt-check` both pass. - [x] Run against a local `redap` (with `REDAP_ARTIFICIAL_LATENCY_MS=100`) from Python: ``` BenchmarkResult(rtt=103.0 ms, bandwidth=108.8 MiB/s) BenchmarkResult(rtt=102.1 ms, bandwidth=111.0 MiB/s) # num_bytes=1 MiB BenchmarkResult(rtt=102.7 ms, bandwidth=114.7 MiB/s) # num_bytes=64 MiB ``` RTT matches the configured artificial latency; bandwidth scales up with payload as fixed overhead amortizes. Follow-ups (not blockers for this PR): - Run against a deployed stack and sanity-check reported numbers. - Confirm the response is not transparently compressed by the proxy chain (verify `Content-Encoding` / payload size on the wire). Closes [RR-4526](https://linear.app/rerun/issue/RR-4526/bandwidth-measurement-endpoint-on-cloud). Source-Ref: ff41c42cf26a3886096cdd38c99b0d0a8a4ab26a

2026-04-27

Make task cancellation API public, add `.cancel()` on RegistrationHandle ### Related Functionality originally added in https://github.com/rerun-io/reality/pull/962 ### What Previously, cancelling tasks was a "private" (actually publicly accessible, but staff-only) GRPC endpoint. Now, it becomes part of our official protocol, and is exposed in the Python SDK through the `RegistrationHande.cancel` method. ### Testing - [x] AWS ### Compatibility This moves the CancelTasks method from the private protocol to the public one. From now on, any changes to it will be considered breaking, but otherwise this is fine. Source-Ref: 02a83f7552e89db8208c39727dee053bc7d062a1

2026-03-31

Sync releases 0.31.0 and 0.31.1 (#12715) ### Related * Contains all changes from #12710. * Contains all changes from #12714. * Supersedes #12713. ### What Sync PR. Includes upgraded `nightly` version for doc publishing workflow. Source-Ref: f79063fc3bc37ef7600724f6476ed49b7ac832e3

fmt pb

2026-03-30

Add direct fetching from S3, use it in SDK ### Related Closes RR-4036 [Notion doc](https://www.notion.so/rerunio/Fetching-chunks-from-the-client-31fb24554b1980a7bfc3e21e94e1e9aa) ### What `QueryDatasetRequest` now has a new parameter where the client can ask to include direct (presigned) URLs to layer files in S3. The SDK makes use of this, with a fallback to the old GRPC path. The viewer is unaffected for now. ### Testing - [X] AWS - [x] Azure ### TODO - [x] Azure permissions - [x] Clean up debug env var, logs(?) ### Compatibility This is a backwards-compatible change server-side, but non-backwards-compatible on the SDK side. This means that an old SDK can talk to a new server, but a new SDK is not guaranteed to work with an old server that does not support the new parameter. This is allowed under our backwards compat rules. --------- Source-Ref: a6d629b9e6043fc69997aac53aa0e465478078fb Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com> Co-authored-by: mailmindlin <mailmindlin@users.noreply.github.com>

fmt pb

2026-03-27

Add cloud provider details to end point ### Related Cost savings efforts and improving the management of our various stacks. ### What Adds a cloud provider endpoint so we can better automate registration for our stacks https://rerunio.slack.com/archives/C09FQBVHHC1/p1771957459917499 This moves us in a direction to simplify dataset_util and hopefully get around to removing it entirely. ### Testing * Added e2e test * Add OSS specific test * Didn't test again local/cloud redap ### Compatibility This adds new fields onto the protobuf so things should be compatible. There is slight risk for addition of any API surface that our client and cloud are aligned. If this lands in 0.31 then we will want to make sure to cherry-pick into 0.10 so that the cloud endpoint exists for the client to call. Source-Ref: 65ccb39b0baff6d536b0ff8898e52fa25c740236

2026-03-26

Add `WhoAmI` gRPC endpoint for verifying client auth This makes it much easier to track login attempts and their results. Source-Ref: 0e6e15c88debbe404536a81fa81800549e59e202

2026-03-24

Fix broken link and resolve trivial URL redirects ## Summary - Fix broken link to `movable-type.co.uk` (site is down) with an archive.org URL - Update `http://rerun.io` → `https://rerun.io` across the codebase - Update `http://scripts.sil.org/OFL` → `https://openfontlicense.org` - Resolve 14 rerun.io doc path redirects to their current destinations (e.g. `/docs/getting-started/troubleshooting` → `/docs/overview/installing-rerun/troubleshooting`) --------- Source-Ref: 800344f08cd30b4bcf0aa255cf77a42b6a02f5ab Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-06

proto fmt

2026-02-12

Actually support multi-layered `/GetRrdManifest` for realsies `/GetRrdManifest` was never updated since its very hacky meetup-induced inception. It never really supported layered segments, nor deletions, let alone mixtures of both. It does now.. I think. --- So I can see at least 3 distinct categories of bugs: * [x] Multi-layered /GetRrdManifest breaks in all kinds of ways * [x] Multi-layered deletion is gonna break in all kinds of ways * [x] Multi-layered schema hashing is just plain broken TODO: * [x] Check snapshots make sense * [x] Manually test the canary dataset * [x] Self-review Source-Ref: 082b48170ec6dbd8271560a55c5a3b3f4432a158

The `url` argument of `CatalogClient.create_table()` is now a prefix Source-Ref: 959bb839992731b012aaef479def07e8fafccbca

2026-02-11

Atomic (un)registrations Implements: * Atomic registration via status CAS loop * Unregistration (also atomic) in OSS, DPF & Python SDK --- * Closes https://linear.app/rerun/issue/RR-3507/atomic-rrd-registrations * Closes https://linear.app/rerun/issue/RR-3483/deleteunregister-segments --- TODO: * [x] address remaining TODOs * [x] `--force` * [x] make sure all snapshots make sense * [x] self-review * [x] embark @andrea-reale on an emotional review journey * [x] also ask him if he can think of any `deleted_filter` I might have missed * [x] also ask him why the errors i get on the client always miss the valuable source info * [x] does the DM have a scalar index on status? should it? * [x] at least make an issue Source-Ref: e37dc1646b4bcad4572b98b2e551202f42c79c03

2026-01-29

Add compression support to `DataframePart` `DataframePart` is what we use to transport and/or store any Arrow data that doesn't belong to a Chunk. This includes but isn't limited to: RRD manifests, segment tables, task reports, etc. This generally reduce data size by around 10x, which can make a lot of difference when it comes to using the dataplatform over a standard connection. For BW compatibility reason, we cannot enable this by default yet. But getting this in right now will make it possible to enable this broadly starting with 0.30. Source-Ref: 7a2210017976097b7b42e1ae06f2a616017fa63d

Add compression support to `DataframePart` `DataframePart` is what we use to transport and/or store any Arrow data that doesn't belong to a Chunk. This includes but isn't limited to: RRD manifests, segment tables, task reports, etc. This generally reduce data size by around 10x, which can make a lot of difference when it comes to using the dataplatform over a standard connection. For BW compatibility reason, we cannot enable this by default yet. But getting this in right now will make it possible to enable this broadly starting with 0.30. Source-Ref: 7a2210017976097b7b42e1ae06f2a616017fa63d

Add version field to gRPC VersionResponse Add a `version` field to `VersionResponse` that exposes a single version string for the whole stack. The value comes from the `$EXPOSED_VERSION` environment variable, defaulting to "undefined" if not set or empty. Source-Ref: 8357e6b8fa90588411988d76161c85eaa5314a11 (cherry picked from commit e4fcf684b997337d6ec3b4ee43999371a403f854)

2026-01-28

Add version field to gRPC VersionResponse Add a `version` field to `VersionResponse` that exposes a single version string for the whole stack. The value comes from the `$EXPOSED_VERSION` environment variable, defaulting to "undefined" if not set or empty. Source-Ref: 8357e6b8fa90588411988d76161c85eaa5314a11

2026-01-21

Experimental python API for taking viewer screenshots Co-authored-by: Andreas Reich <r_andreas2@web.de> Source-Ref: 0bb67f5af9231fc6e1f599d4c9f49e72906914bd

2026-01-12

plumb through message to viewer. or at least into the vincinity

2026-01-07

`/GetRrdManifest` on Rerun Cloud (#12323) This implements all the necessary OSS changes so that `/GetRrdManifest` on Rerun Cloud can become a reality. The sibling PR takes care of the actual endpoint implementation in Rerun Cloud. Specifically: * Make `/GetRrdManifest` a proper end-to-end stream. * Tweak the test suite so that it doesn't track any implementation-specific concerns. The protobuf breaking changes are on purpose. --- * Part of https://linear.app/rerun/issue/RR-3110/implement-get-rrd-manifest-on-rerun-cloud * Sibling: https://github.com/rerun-io/dataplatform/pull/2206 * DNM: should be merged at the same time as the sibling

2026-01-06

implement end-to-end streaming for /GetRrdManifest

2026-01-05

Add test coverage for `QueryDatasetRequest.query` (#12266)

2025-12-22

Allow tables to be created without providing a URL (#12132) Fixes [RR-3012](https://linear.app/rerun/issue/RR-3012/default-write-location-for-create-table) The `url` parameter in `create_table_entry` is now optional. When it's `None`, the OSS server will create the Lance table in a temporary directory that will be deleted when the process exists. The path used is `$TMPDIR/rerun-data-<xxx>/lance-<some-tuid>`, e.g. `$TMPDIR/rerun-data-jYteWy/lance-187E63126233FA3A3f7ce35ea997f9c8` --------- Co-authored-by: Antoine Beyeler <49431240+abey79@users.noreply.github.com>

2025-12-16

`/GetRrdManifest` now returns actual `RrdManifest`s (#12222) Title. In addition: * `chunk_byte_size` & `chunk_byte_offset` are always mandatory * they are filled with uncompressed values in contexts where compressed values cannot be computed (e.g. the OSS server, where there is no disk involved and thus no compression) > ## Understand size/offset columns > > * `chunk_byte_size` & `chunk_byte_offset` are always reported using the backend's native > storage size. For a backend that makes use of compression, such as an RRD file with > compression enabled, these sizes are therefore compressed. For a backend that doesn't do any > kind of compression, such as the OSS server that stores everything already decoded in memory, > these sizes will correspond to heap memory usage. > * `chunk_byte_size_uncompressed` always corresponds to the size on the heap that the data would > require once fully decoded, regardless of the backend. > * `chunk_key`, if specified, should always be used to fetch the associated data. * `chunk_key` is optional gRPC breaking changes on purpose: unpublished API. --- * Fixes https://linear.app/rerun/issue/RR-3182/getrrdmanifest-needs-to-return-an-actual-rrdmanifest

2025-12-04

Partition-to-segment rename (wave 4): rename everything else (#12085)

Fetch RRD manifests from OSS server (#12076) ## Related * Part of RR-3110 * Sibling PR: https://github.com/rerun-io/dataplatform/pull/2101 ## What The attached test summarizes everything you need to know. `server.get_rrd_manifest("my_segment_id")` yields something like the following: <img width="1303" height="749" alt="image" src="https://github.com/user-attachments/assets/7433ffee-19c6-4e0b-a409-38bb184502dc" /> Note the absence of `chunk_byte_size`/`chunk_byte_offset`, replaced by `chunk_key` instead. ## TODO * [x] ignore unimplemented errors in the redap_test --------- Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>

2025-12-03

RRD footers 2: RRD manifests (#12047) LLM summary: > This PR introduces RRD manifest support as the second part of the RRD footers series. The manifest provides an index of chunks in an RRD recording, enabling efficient query planning without loading actual data. Key changes include: > - Extending `RrdFooter` and adding `RrdManifest` protobuf definitions > - Implementing `RrdManifest` and `RrdManifestBuilder` to catalog chunks with their metadata (ID, size, offset, timeline ranges) > - Adding transport layer conversions between application-level and protobuf types > - Refactoring schema hash computation to a shared utility method To which I'll add: This PR introduces the core datastructure that this whole footer business is all about: the `RrdManifest`. The `RrdManifest` is a protobuf message (which, as always, comes with both a transport-level and application-level implementations) which carries various important metadata about the associated recording. The most important piece of metadata is the actual manifest record-batch, which lists all the chunks in the recording at at fine-grained enough level of detail that relevancy queries become possible without ever having to load the data in a local chunk-store first. Effectively, you can view record-batch is a dataframe representation of the time panel. There is a lot of code, but it's all fairly trivial and mechanical, bordering on boilerplate in some cases. In fact, what you should really focus on is the fact that this code: https://github.com/rerun-io/rerun/blob/ad754fab94517e80866f7911164a7622b932de74/crates/store/re_log_encoding/tests/footers_and_manifests.rs#L116-L173 yields this manifest record-batch: <img width="1137" height="1468" alt="image" src="https://github.com/user-attachments/assets/c7548fb8-4ea0-47fd-98c6-3783c2095e85" /> with this schema: https://github.com/rerun-io/rerun/blob/ad754fab94517e80866f7911164a7622b932de74/crates/store/re_log_encoding/tests/snapshots/footers_and_manifests__simple_manifest_batch_schema.snap#L5-L117 --- Part of RRD footers series of PRs: * https://github.com/rerun-io/rerun/pull/12044 * https://github.com/rerun-io/rerun/pull/12047 * https://github.com/rerun-io/rerun/pull/12048 * https://github.com/rerun-io/dataplatform/pull/2060 --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

RRD footers 1: framing (#12044) LLM summary: > This PR introduces the foundational framing infrastructure for RRD stream footers, which will enable richer metadata and improved stream navigation. It establishes the protocol-level types and state machine changes needed to support footers without yet populating them with content. > > Key changes include: > - Addition of `RrdFooter` message types at both transport (protobuf) and application levels > - Introduction of `StreamFooter` frame for locating and validating RRD footers > - Enhanced decoder state machine to handle the new footer frames > - Updated encoder to emit footers with basic state tracking infrastructure To which I would add the following: This introduces all the framing infrastructure so that RRD streams are now capable of carrying footers in all circumstances (including pipes). Specifically, this introduces a couple new types: * `RrdFooter`, a(n empty) protobuf message that will from now on act as the payload for messages of type `MessageKind::End`. * `MessageKind::End` isn't new, it's something that was always there, but until now was always empty. * As always, this has both a cheap transport-level definition and a less cheap app-level definition. * `StreamFooter`, a simple binary frame that mirrors `StreamHeader`, and whose main job is to keep track of where the `RrdFooter`. * This is used for O(1) access to the `RrdFooter`, e.g. when registering data on a Redap-compliant server. For now, these footers are always an empty protobuf messages. We will be filling them up in the following PRs. --- Part of RRD footers series of PRs: * https://github.com/rerun-io/rerun/pull/12044 * https://github.com/rerun-io/rerun/pull/12047 * https://github.com/rerun-io/rerun/pull/12048 * https://github.com/rerun-io/dataplatform/pull/2060 ## TODO * [x] `@rerun-bot full-check` --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

2025-12-02

protobuf definitions for RRD manifest

RRD footers: everything framing

Partition-to-segment rename (wave 1): redap layer (#12017)

2025-11-19

DPF: create_index: deprecate num_partitions (#11920)

2025-11-17

Add ability to replace/upsert in tables (#11812) ### Related Closes https://linear.app/rerun/project/add-ability-to-upsert-data-in-tables-aad5989947ac ### What This PR follows up on the work from https://github.com/rerun-io/rerun/pull/11694 and the issues linked inside it. With this PR you can update existing tables if they have an index specified as a primary key. You do this by setting the metadata `rerun:is_table_index` on the field when creating the table. During `update` operations we will use these columns as the keys by which we update the underlying lance table.

2025-11-03

Index management APIs: Python bindings, types cleanup, and index statistics (#11729) Title. * Related: https://linear.app/rerun/issue/RR-2824/the-index-management-apis-need-actual-design (which is breadcrumbed throughout the code) --- Demo: ```py from __future__ import annotations import sys import json import rerun as rr def create_vector_index(dataset, num_partitions, num_sub_vectors) -> rr.IndexingResult: """Create a vector index for the embeddings columns.""" embedding_column = rr.dataframe.ComponentColumnSelector("/camera/wrist/embedding", "embeddings") return dataset.create_vector_index( column=embedding_column, time_index=rr.dataframe.IndexColumnSelector("real_time"), num_partitions=num_partitions, num_sub_vectors=num_sub_vectors, distance_metric="Cosine", ) addr = "rerun+http://localhost:51234" client = rr.catalog.CatalogClient(addr) dataset = client.get_dataset(name=sys.argv[1]) print() print("cleaning up all existing indexes...") for index in dataset.list_indexes(): deleted = dataset.delete_indexes(index.column) print(f"index deleted: {deleted} {json.dumps(json.loads(index.statistics), indent=4)}") print() for [num_partitions, num_sub_vectors] in [[8, 8], [2, 2]]: print("====") created = create_vector_index(dataset, num_partitions, num_sub_vectors) print(f"index created: {created.properties} {created.debug_info()} {json.dumps(json.loads(created.statistics), indent=4)}") deleted = dataset.delete_indexes(created.column) print(f"index deleted: {deleted}") ``` ``` RUST_LOG=off pixi run -e examples python create_vector_index.py droid:sample50 8 8 DEV ENVIRONMENT DETECTED! Re-importing rerun from: /home/cmc/dev/rerun-io/rerun/rerun_py/rerun_sdk cleaning up all existing indexes... index deleted: [IndexConfig('/camera/wrist/embedding:embeddings' on 'real_time': VectorIvfPq { num_partitions: 5, num_sub_vectors: 16, metric: cosine })] { "index_type": "IVF_PQ", "name": "instance_idx", "num_indices": 1, "updated_at_timestamp_ms": 1761906652272, "num_indexed_fragments": 1, "num_indexed_rows": 13537, "num_unindexed_fragments": 0, "num_unindexed_rows": 0, "num_indexed_rows_per_delta": [ 13537 ] } ==== index created: '/camera/wrist/embedding:embeddings' on 'real_time': VectorIvfPq { num_partitions: 8, num_sub_vectors: 8, metric: cosine } None { "index_type": "IVF_PQ", "name": "instance_idx", "num_indices": 1, "updated_at_timestamp_ms": 1761906752176, "num_indexed_fragments": 1, "num_indexed_rows": 13537, "num_unindexed_fragments": 0, "num_unindexed_rows": 0, "num_indexed_rows_per_delta": [ 13537 ] } index deleted: [IndexConfig('/camera/wrist/embedding:embeddings' on 'real_time': VectorIvfPq { num_partitions: 8, num_sub_vectors: 8, metric: cosine })] ==== index created: '/camera/wrist/embedding:embeddings' on 'real_time': VectorIvfPq { num_partitions: 2, num_sub_vectors: 2, metric: cosine } None { "index_type": "IVF_PQ", "name": "instance_idx", "num_indices": 1, "updated_at_timestamp_ms": 1761906752762, "num_indexed_fragments": 1, "num_indexed_rows": 13537, "num_unindexed_fragments": 0, "num_unindexed_rows": 0, "num_indexed_rows_per_delta": [ 13537 ] } index deleted: [IndexConfig('/camera/wrist/embedding:embeddings' on 'real_time': VectorIvfPq { num_partitions: 2, num_sub_vectors: 2, metric: cosine })] ``` --- * Sibling: https://github.com/rerun-io/dataplatform/pull/1947 * DNM: requires #11693

Index management APIs (#11693) What the title says: * Introduce the new `ListIndexes` and `DeleteIndexes` * Introduce a cross-impl test suite that follows the entire lifecycle of an index: * `CreateIndex` * `ListIndexes` * `SearchDataset` * `DeleteIndexes` --- * Part of: https://linear.app/rerun/issue/RR-2734/include-sdk-api-to-delete-an-index * Sibling: https://github.com/rerun-io/dataplatform/pull/1926

2025-10-31

all of it

Find replace partition with segment

2025-10-29

Merge remote-tracking branch 'origin/main' into cmc/delete_index

Create lance tables in the cloud (#11640) ### Related This is a follow on to https://github.com/rerun-io/rerun/pull/11565 It addresses a portion of https://linear.app/rerun/project/write-tables-to-rerun-cloud-via-the-python-sdk-432c0243348f/overview ### What With this PR we introduce a new server API to create a table from a given Schema. The current work will create a Lance based table. This table is registered with the server and available for immediate writing using #11565 Additionally this PR adds the integration testing in `re_redap_tests`

introducing new cloud APIs for index mgmt

Add a new `target_partition_num_rows` API parameter to the CreateIndex API (#11686) ### What The old way of specifying `num_partitions` is now deprecated. See: https://docs.rs/lance-index/0.38.2/lance_index/vector/ivf/builder/struct.IvfBuildParams.html#structfield.num_partitions Lance exposes a new `target_partition_size` parameter which gives me predictable performance instead of users manually needing to increase the number of partitions as the size of the dataset increases. This works better for things like incremental indexing. Resolves: RR-2772 --------- Co-authored-by: Clement Rey <cr.rey.clement@gmail.com>

Return optional DebugInfo with `memory_used` as part of CreateIndexResponse (#11691) ### Related - RR-2797 ### What This plumbs through an optional DebugInfo from the server. We expose this as part of a new IndexingResult returned from `create_vector_index`. `debug_info()` itself is exposed to python simply as a dictionary so we can more easily add more data here without worrying about API changes.

2025-10-28

Implicit optional message

[api] Include optional DebugInfo as part of the CreateIndex api response

Rename size -> num_rows

wip

TODO / docstrings

[api] Add target_partition_size to CreateIndex grpc

Switch create table entry to use provider_details to follow same pattern as other messages

Add CreateTable to proto and server

Add CreateTable to proto and server Add test for create_table Impl helper method Switch create table entry to use provider_details to follow same pattern as other messages Switch from passing string to url in create_table function Add python function for calling create table and a unit test Add unit test to verify we have rerun metadata as expected Reorder arguments so we can make path optional in follow on work

Improve column projection specification and implement it for OSS server (#11687) Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

2025-10-27

wip

Simplify `CreateIndexResponse` (#11654)

2025-10-24

CreateIndexResponse crumbles into nothingness

Switch create table entry to use provider_details to follow same pattern as other messages

Add CreateTable to proto and server

add table writing to lance table providers (#11565) ### Related Addresses part of https://linear.app/rerun/project/write-tables-to-rerun-cloud-via-the-python-sdk-432c0243348f/overview ### What This PR is foundational to our ability to write to any kind of table on the data platform. Included in this PR is enabling `insert_into` for our gRPC based table providers. This also includes updates to the OSS server to support table writing. We cannot merge this PR until the following are completed: - [x] Add identical support to data platform - [x] Add python integration tests

Simplify `CreateIndexRequest` (#11636) The interesting stuff will happen in the sibling (and its children). * Part of https://linear.app/rerun/issue/RR-2741/simplify-reruncloudservicecreateindex * Sibling: https://github.com/rerun-io/dataplatform/pull/1898

2025-10-23

Add CreateTable to proto and server

Limit scope of write mode to append and overwrite

Proto lint

More rebase issues

Update protos since we will get the entry ID from the header not the message

Add proto definition for writing tables

simplify CreateIndexRequest

2025-10-22

Limit scope of write mode to append and overwrite

2025-10-21

Proto lint

More rebase issues

Update protos since we will get the entry ID from the header not the message

Add proto definition for writing tables

`re_log_encoding` v2 (#11582) A complete rewrite of `re_log_encoding` that pays off the organically grown debt and sprinkles a couple years of hindsight on top. This also closes the "one encoder/decoder to rule them all" story. Apologies, I really wanted to split this into multiple PRs, but everything I've tried turned into a dependency nightmare. All the code in `re_log_encoding` is new, so you can just ignore the diff entirely for that folder and look directly at the code, really. The docs are shit, but there is so much hidden complexity and so much context required, I'm never going to get them right on first try anyway. Suggestions welcome. I've put as reviewers all the people that got a live walkthrough. For everyone else, here's an excerpt from the docs of the new `re_log_encoding` to get an idea of what's going on: > This crate covers two equally important but orthogonal matters: > * Converting between transport-level and application-level Rerun types. > * Encoding and decoding Rerun RRD streams. > > If you are working with one of the gRPC APIs (Redap or SDK comms), then you want to be looking > at the [`ToTransport`]/[`ToApplication`] traits. The [`rrd`] module is completely irrelevant in > that case. You can learn more about these traits below. > > If you are working with actual RRD streams (i.e. everything that does not go through gRPC: > files, standard I/O, HTTP, data loaders, etc), then have a look into the [`rrd`] module. > The [`ToTransport`]/[`ToApplication`] traits will also be useful to you. You can learn more > about these traits below. > > ## What are transport-level and application-level types? > > To put it in simple terms: transport-level types are the types that you find in `re_protos`, while > application-level types are those that you find in `re_log_types`. > > More generally, transport-level types are Rust objects that represent the decoded value of some > Rerun bytes, *and nothing more than that*. It's all they do: they map raw bytes to their native > Rust representation and vice-versa. They never apply any application-level logic beyond that. > > Transport-level types are used to unopinionatedly transport Rerun data across the many mediums > that Rerun support, while application-level types are used to build applications for end-users, > such as the Rerun viewer itself. > > Application-level types on the other hand are *very* opinionated, and often perform a lot of > transformations on the data, including but not limited to: > * Chunk/Sorbet migrations > * Application ID injection > * SDK version patching > * Backward-compatibility shenanigans > * Etc > > Application-level can _not_ be encoded/decoded, only transport-level types can. To encode an > application-level type, you must first convert it to transport-level type. > You can do so by using the [`ToApplication`] & [`ToTransport`] traits exposed by this crate. > > ## How do I make sense of all these different `LogMsg` types?! > > There are 3 different `LogMsg`-related types that you will very often encounter: `re_log_types::LogMsg`, > `re_protos::log_msg::v1alpha1::LogMsg` and `re_protos::log_msg::v1alpha1::log_msg::Msg`. > > Mixing them up is a common source of pain and confusion, so let's go over what each does: > * `re_log_types::LogMsg` is the application-level type that we use all across the viewer > codebase. It can be obtained by calling `to_application()` on one of the transport-level > `LogMsg` types which, among many other things, will perform Chunk/Sorbet-level migrations. > `re_log_types::LogMsg` isn't used in Redap, where everything is done at the transport-level, always. > * `re_protos::log_msg::v1alpha1::LogMsg` is the transport-level definition of `LogMsg`. It is an > artifact of how `oneof` works in Protobuf: all it does is carry a `re_protos::log_msg::v1alpha1::log_msg::Msg`. > For that reason, it is never directly used, except by the legacy SDK comms protocol. > * Finally, `re_protos::log_msg::v1alpha1::log_msg::Msg` is the real transport-level type that we > care about. It is used all over the place when encoding and decoding RRD streams. > > ## What are the different protocols supported by Rerun? > > Rerun currently supports 3 protocols: > * Redap (Rerun Data Protocol): our gRPC-based protocol used by our OSS and proprietary data platforms. > * SDK comms: our legacy gRPC-based protocol, currently used by everything relying on the old > `StoreHub` model (logging, message proxy, etc). > * RRD streams: the binary protocol that we use for all stream-based interfaces (files, stdio, > data-loaders, HTTP fetches, etc). > > *All these protocols use the exact same encoding*. There is only one encoding: the Rerun encoding. > It often happens that one protocol makes use of some types while others don't (e.g. the > top-level `LogMsg` object is never used in RRD streams, but is used in SDK comms), but for all > the types they do share, the encoding will be the exact same. * Sibling: https://github.com/rerun-io/dataplatform/pull/1873

2025-10-20

implement registration by prefix: OSS server (#11564) ### Related - RR-1962 - dataplatform-side change: https://github.com/rerun-io/dataplatform/pull/1864 ### What This implements, in the OSS server, a variant of `register_with_dataset` that allows data sources to be `prefix`-based paths. ``` ### What next This won't be usable by the SDK as is (i.e., the SDK will not let you register by prefix until we add support for it) --------- Signed-off-by: Andrea Reale <andrea@rerun.io> Co-authored-by: Antoine Beyeler <antoine@rerun.io>

2025-10-19

docs docs docs

re_log_encoding v2

wip

2025-10-17

wip

fix RerunChunk.payload not being marked explicitly optional before it's too late

2025-10-16

wip

Update protos since we will get the entry ID from the header not the message

Add proto definition for writing tables

2025-10-15

fix RerunChunk.payload not being marked explicitly optional before it's too late

2025-10-14

fix RerunChunk.payload not being marked explicitly optional before it's too late

Fix data corruption during compression of large chunks (#11525) There are 3 problems involved: 1. `ArrowMsg::uncompressed_size` is defined as an `int32`. That issue speaks for itself. 2. The encoding path tracks payload sizes using `usize`, and then silently cast them to `int32` when encoding the Protobuf data, leading to gibberish and crashes during decoding. 3. `lz4_flex` has similar casting bugs: it can encode 64bit values but cannot decode them. Once again the `as` keyword is involved. This PR fixes 1 and 2. All the changes are backward and forward compatible because: * In protobuf, `uint64` is a strict superset of `int32`: both are unsigned varints on the wire. * There exist no valid RRD files out there with negative values for `uncompressed_size`. We can already log much bigger chunks than before, but not too big, otherwise `lz4` itself will during decoding: ``` thread 'decompress' panicked at 'attempt to add with overflow' lz4_flex-0.11.5/src/block/decompress_safe.rs:39 stack backtrace: 6: core::panicking::panic_fmt at core/src/panicking.rs:75:14 7: core::panicking::panic_const::panic_const_add_overflow at core/src/panicking.rs:175:17 8: std::sys::backtrace::__rust_begin_short_backtrace 9: core::ops::function::FnOnce::call_once{{vtable.shim}} 10: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at alloc/src/boxed.rs:1966:9 <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at alloc/src/boxed.rs:1966:9 std::sys::pal::unix::thread::Thread::new::thread_start at std/src/sys/pal/unix/thread.rs:97:17 11: <unknown> 12: <unknown> ``` I'll have a follow-up PR for the `lz4_flex` issue. --- * Half of fixing https://github.com/rerun-io/rerun/issues/11516 * The other half requires patching `lz4_flex` (on it) --- Checks: * [x] `rerun` with `--nb_scans 2000` * [x] `rerun rrd stats` with `--nb_scans 2000` * [x] :no_entry: `rerun` with `--nb_scans 3000` -> bug in lz4 * [x] :no_entry: `rerun rrd stats` with `--nb_scans 3000` -> bug in lz4 * [x] All dataplatform test suites pass * [x] Can load old RRDs no problem

Fix data corruption during compression of large chunks (#11525) There are 3 problems involved: 1. `ArrowMsg::uncompressed_size` is defined as an `int32`. That issue speaks for itself. 2. The encoding path tracks payload sizes using `usize`, and then silently cast them to `int32` when encoding the Protobuf data, leading to gibberish and crashes during decoding. 3. `lz4_flex` has similar casting bugs: it can encode 64bit values but cannot decode them. Once again the `as` keyword is involved. This PR fixes 1 and 2. All the changes are backward and forward compatible because: * In protobuf, `uint64` is a strict superset of `int32`: both are unsigned varints on the wire. * There exist no valid RRD files out there with negative values for `uncompressed_size`. We can already log much bigger chunks than before, but not too big, otherwise `lz4` itself will during decoding: ``` thread 'decompress' panicked at 'attempt to add with overflow' lz4_flex-0.11.5/src/block/decompress_safe.rs:39 stack backtrace: 6: core::panicking::panic_fmt at core/src/panicking.rs:75:14 7: core::panicking::panic_const::panic_const_add_overflow at core/src/panicking.rs:175:17 8: std::sys::backtrace::__rust_begin_short_backtrace 9: core::ops::function::FnOnce::call_once{{vtable.shim}} 10: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at alloc/src/boxed.rs:1966:9 <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at alloc/src/boxed.rs:1966:9 std::sys::pal::unix::thread::Thread::new::thread_start at std/src/sys/pal/unix/thread.rs:97:17 11: <unknown> 12: <unknown> ``` I'll have a follow-up PR for the `lz4_flex` issue. --- * Half of fixing https://github.com/rerun-io/rerun/issues/11516 * The other half requires patching `lz4_flex` (on it) --- Checks: * [x] `rerun` with `--nb_scans 2000` * [x] `rerun rrd stats` with `--nb_scans 2000` * [x] :no_entry: `rerun` with `--nb_scans 3000` -> bug in lz4 * [x] :no_entry: `rerun rrd stats` with `--nb_scans 3000` -> bug in lz4 * [x] All dataplatform test suites pass * [x] Can load old RRDs no problem

2025-10-08

remove internal tasks operations from cloud public API (#11447)