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

Handle loading of blueprint with same StoreId as active blueprint #5514

Open
emilk opened this issue Mar 14, 2024 · 0 comments
Open

Handle loading of blueprint with same StoreId as active blueprint #5514

emilk opened this issue Mar 14, 2024 · 0 comments
Labels
🟦 blueprint The data that defines our UI 🪳 bug Something isn't working

Comments

@emilk
Copy link
Member

emilk commented Mar 14, 2024

We stream-load all recordings and blueprints into a StoreBundle, which indices the stores based on StoreId.

This means that if we load a blueprint with the same StoreId as the current active one, we will progressively stream into the active blueprint, which can cause havoc on it. We only want to make a blueprint active once it is fully loaded.

A repro of this is to save a blueprint file, drag-drop it into the viewer, then drag-drop it once again into the viewer.

Current work-around

Each blueprint gets assigned a random store_id on save, which makes the chance of a store-id collision small.

There is also a warning printed if we still run into the problem.

Solutions A (the bad one)

Change store_id of blueprints as they load, or once they finish loading to something new and random.

Solution B (the slightly better one)

While loading blueprints, store then outside the main StoreHub/StoreBundle. Once they finish loading, move them into the main StoreHub.

Note that data recordings should still go into the main StoreHub because we stream those in.

@emilk emilk added 🪳 bug Something isn't working 🟦 blueprint The data that defines our UI labels Mar 14, 2024
emilk added a commit that referenced this issue Mar 15, 2024
### What
* Part of #5294

This implements loading of blueprint files (.rbl) on native and on web,
using either drag-and-drop of the `Open…` command.

One shortcoming of the approach in this PR is documented here:
* #5514

### Checklist
* [x] I have read and agree to [Contributor
Guide](https://github.com/rerun-io/rerun/blob/main/CONTRIBUTING.md) and
the [Code of
Conduct](https://github.com/rerun-io/rerun/blob/main/CODE_OF_CONDUCT.md)
* [x] I've included a screenshot or gif (if applicable)
* [x] I have tested the web demo (if applicable):
* Using newly built examples:
[app.rerun.io](https://app.rerun.io/pr/5513/index.html)
* Using examples from latest `main` build:
[app.rerun.io](https://app.rerun.io/pr/5513/index.html?manifest_url=https://app.rerun.io/version/main/examples_manifest.json)
* Using full set of examples from `nightly` build:
[app.rerun.io](https://app.rerun.io/pr/5513/index.html?manifest_url=https://app.rerun.io/version/nightly/examples_manifest.json)
* [x] The PR title and labels are set such as to maximize their
usefulness for the next release's CHANGELOG
* [x] If applicable, add a new check to the [release
checklist](https://github.com/rerun-io/rerun/blob/main/tests/python/release_checklist)!

- [PR Build Summary](https://build.rerun.io/pr/5513)
- [Docs
preview](https://rerun.io/preview/9b3e7d9aed9113d340516caed9d87897c8ae8abb/docs)
<!--DOCS-PREVIEW-->
- [Examples
preview](https://rerun.io/preview/9b3e7d9aed9113d340516caed9d87897c8ae8abb/examples)
<!--EXAMPLES-PREVIEW-->
- [Recent benchmark results](https://build.rerun.io/graphs/crates.html)
- [Wasm size tracking](https://build.rerun.io/graphs/sizes.html)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🟦 blueprint The data that defines our UI 🪳 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant