-
Notifications
You must be signed in to change notification settings - Fork 539
Introduce ConnectionRegistry
for centralised redap client and token management
#10078
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
Conversation
Web viewer built successfully. If applicable, you should also test it:
Note: This comment is updated whenever you push a commit. |
ConnectionRegistry
for centralised redap client and token management
148da13
to
1f28051
Compare
crates/viewer/re_viewer/src/app.rs
Outdated
app_env: &crate::AppEnvironment, | ||
startup_options: StartupOptions, | ||
creation_context: &eframe::CreationContext<'_>, | ||
connection_registry: Option<ConnectionRegistry>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make do without that as argument, and a App::add_token(origin, token)
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is annoying because of how entrypoints.rs
and streaming works. We start streaming data before creating App
, this this requires a connection registry (seeded with --token
). If App
would create it's own registry, the following sequence would apply:
- create a temp registry with
--token
if any - kick off stream with temp registry
- create
App
- set the
--token
again onApp
's registry
with the added downside that App
's registry doesnt inherit from the connection established by stream
(not that it's a huge deal).
Also, see:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! thanks again for the walkthrough
) ### Related - closes https://github.com/rerun-io/dataplatform/issues/726 - closes https://github.com/rerun-io/dataplatform/issues/721 - part of https://github.com/rerun-io/dataplatform/issues/750 - part of https://github.com/rerun-io/dataplatform/issues/763 - follow-up to #10078 - DNM: chained ### What This PR introduce the concept of "fallback token", which is essentially the same as the `REDAP_TOKEN` env var for the purpose of the web viewer. It is now automatically set from the enclosing notebook environment, if that environment has `REDAP_TOKEN` set. Thanks @jprochazk for the help 🙏🏻
### Related - Follow up to #10078 ### What One should not hold to a `RedapClient` for extended periods of time, as they might need to be periodically refreshed in the future (for auth purposes). This PR changes the SDK implementation such that it always gets a fresh copy of the client instead of holding on to the same one forever.
Related
--token
option to the rerun CLI #10068What
This PR introduces a new
ConnectionRegistry
structure to hold on open redap connections and known tokens.userdev-facing change is thatRedapClient
are now locally sourced from your friendly neighbourhoodConnectionRegistry
.re_grpc_client::redap::client
is no longerpub
.App
. In the future, the entrypoint may pre-populate it with token passed from the CLI.CatalogClient
now has an optionaltoken
argument.REDAP_TOKEN
env variable is still used, but is overridden by any user provided token.Todo
dataplatfom
will need a quickuse
fix after landing this