feat(web): bump to 6.3.0-rc2 and adopt new metrics, quality score, logs - #841
Merged
Conversation
Contributor
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
yanziz-nvidia
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@deps/cloudxr/webxr_client/helpers/react/CloudXRComponent.tsx`:
- Around line 566-583: Update the Connecting-state catch around
cxrSession.sendTrackingStateToServer to mirror the existing deferred-callback
error handling: report the failure through the component’s onError/disconnect
recovery path, clear the renderer when not headless before returning, and
preserve the early return after cleanup.
In `@deps/cloudxr/webxr_client/src/App.tsx`:
- Around line 544-556: Update the disconnect handling alongside sessionQuality
so poseSendFps, renderFps, and streamingMetrics are cleared when status is
Disconnected or Error. Preserve the existing non-Connected quality reset and
metricsAccumulator behavior, and ensure the HUD cannot retain values from the
previous session.
In `@deps/cloudxr/webxr_client/src/CloudXR2DUI.tsx`:
- Around line 1054-1057: Enforce a shared finite-integer range of 5–30 for
streamTestDurationSeconds. In deps/cloudxr/webxr_client/src/CloudXR2DUI.tsx
lines 1054-1057, replace truncating parseInt handling with the shared parser and
fall back to getDefaultConfiguration().streamTestDurationSeconds for invalid or
out-of-range values; update deps/cloudxr/webxr_client/src/config/params.ts lines
89-90 to use the same range validator instead of generic numeric validation;
update deps/cloudxr/webxr_client/src/config/resolve.test.ts lines 123-147 to use
5 as the valid sample and add rejected boundary cases.
In `@docs/source/references/oob_teleop_control.rst`:
- Around line 311-313: Update the metric reference in the network metrics table
to use network.loss_score instead of network.network_loss_score, keeping the
existing loss-score description unchanged.
In `@scripts/download_cloudxr_sdk.sh`:
- Line 12: Align is_valid_sdk_layout() and the local installer validation with
the documented optional single top-level directory layout: resolve the wrapper
directory before checking SDK contents, or remove that layout from the
documentation. If wrapped archives remain supported, update the validation error
text near the installer check to describe both accepted layouts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 60bad1db-2518-47cc-8bc4-bb57b5344038
📒 Files selected for processing (19)
deps/cloudxr/.env.defaultdeps/cloudxr/webxr_client/helpers/metricsAccumulator.test.tsdeps/cloudxr/webxr_client/helpers/metricsAccumulator.tsdeps/cloudxr/webxr_client/helpers/metricsUpdates.tsdeps/cloudxr/webxr_client/helpers/react/CloudXRComponent.tsxdeps/cloudxr/webxr_client/helpers/react/PerformanceCanvasImage.tsxdeps/cloudxr/webxr_client/helpers/react/utils.tsdeps/cloudxr/webxr_client/helpers/utils.tsdeps/cloudxr/webxr_client/jest.setup.jsdeps/cloudxr/webxr_client/package.jsondeps/cloudxr/webxr_client/src/App.tsxdeps/cloudxr/webxr_client/src/CloudXR2DUI.tsxdeps/cloudxr/webxr_client/src/CloudXRUI.tsxdeps/cloudxr/webxr_client/src/config/params.tsdeps/cloudxr/webxr_client/src/config/resolve.test.tsdeps/cloudxr/webxr_client/src/index.htmldocs/source/getting_started/build_from_source/webxr.rstdocs/source/references/oob_teleop_control.rstscripts/download_cloudxr_sdk.sh
yanziz-nvidia
marked this pull request as ready for review
July 29, 2026 18:25
aristarkhovNV
approved these changes
Jul 29, 2026
…, logs
Bumps the CloudXR Web SDK from 6.2.0 to 6.3.0-rc2 and adopts the streaming
diagnostics it adds. The bump itself is API-compatible: everything new is
additive (3 SessionOptions fields, 3 delegates, 1 Session method, 17
MetricsName entries, a PerNetwork cadence), and the client builds against
rc2 unchanged.
Session quality and pose send FPS
- Surface MetricsName.SessionQuality (0-4) as a 4-bar signal-strength indicator
on the in-XR HUD, so an operator can see a degrading link before acting on it
rather than inferring it from raw FPS.
- Add a Pose Send FPS card. It measures the uplink command rate, which is what
distinguishes "the video is choppy" from "the robot isn't getting my commands".
- Clear both on disconnect so a dead stream cannot show a stale green reading.
Body tracking capability detection (bug fix)
- Pump sendTrackingStateToServer() while the session is Connecting. The SDK
derives body-tracking support from XRSession.enabledFeatures, which it can only
read from frames delivered before the stream starts. The render loop previously
returned early on state !== Connected, so the SDK never saw such a frame and
full-body teleop could silently degrade to hand/controller only despite the
client requesting bodyTracking.
- Deliberately passes the raw xrFrame rather than trackingFrameAdapter's: during
replay the adapter returns a Proxy with a substituted session, and capability
detection must reflect the real XRSession.
Metrics to the OOB teleop hub
- Report all 21 SDK metrics across the render/frame/network cadences, keyed by
CloudXR.MetricsName, instead of the previous three. New MetricsAccumulator
merges the SDK's partial callbacks so a metric absent from one tick is not
reported as zero, and resets between sessions.
- oob_teleop_hub.py needs no change: it already stores metrics as an arbitrary
{name: value} map per cadence.
SDK logs
- Mirror SDK log entries to the browser console at matching severity. The
onLog/logLevel API existed in 6.2.0; rc2 adds the log content worth surfacing.
Pre-stream network test
- Wire up the SDK's network test with an in-XR countdown and traffic-light
result, defaulting to off: the test holds the session in Connecting for its
whole window, and an operator connecting to a robot should not be gated on it.
Opt in via the settings panel or ?streamTestMode=warn.
- Clamp the configured duration to the [5, 30] second range the SDK accepts, so
the on-panel countdown cannot promise a window shorter than the one that runs.
- Gate message-channel setup on isConnected, not just a non-null session.
Opening a channel sends a control message that requires a connected session,
which would fail during the test window and break the teleop control channel.
Microphone capture and clientToken/signalingHeaders are available in rc2 but not
adopted: the former is an unnecessary permission prompt for robot teleop, and the
latter targets Stream Manager auth rather than this direct-connect deployment.
Frame-rate negotiation was reviewed and left unchanged: this client already
applies the target rate before session creation and passes the effective rate to
CloudXR.
Also drops the isaac/ requirement from the local-tarball layout check, since that
directory is no longer part of the SDK release bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Yanzi Zhu <yanziz@nvidia.com>
renderFps, poseSendFps and streamingMetrics are module-scoped signals that were never cleared, so after a disconnect the in-XR panel kept drawing the previous session's FPS and latency as if they were live. Same class of staleness the session-quality reset already guarded against, but for the numeric cards. Clears them alongside metricsAccumulator.reset() on Disconnected/Error only, so the 'Testing network' transition into a session is unaffected. The computed texts already fall back to '-' on null, so the cards read as empty rather than zero. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yanzi Zhu <yanziz@nvidia.com>
yanziz-nvidia
force-pushed
the
feat/cloudxr-6.3.0-rc2
branch
from
July 29, 2026 20:56
55a1422 to
d898680
Compare
yanziz-nvidia
added a commit
that referenced
this pull request
Jul 30, 2026
…857) * feat(web): bump to 6.3.0-rc2 and adopt new metrics, quality score, logs (#841) * feat(cloudxr): bump to 6.3.0-rc2 and adopt new metrics, quality score, logs Bumps the CloudXR Web SDK from 6.2.0 to 6.3.0-rc2 and adopts the streaming diagnostics it adds. The bump itself is API-compatible: everything new is additive (3 SessionOptions fields, 3 delegates, 1 Session method, 17 MetricsName entries, a PerNetwork cadence), and the client builds against rc2 unchanged. Session quality and pose send FPS - Surface MetricsName.SessionQuality (0-4) as a 4-bar signal-strength indicator on the in-XR HUD, so an operator can see a degrading link before acting on it rather than inferring it from raw FPS. - Add a Pose Send FPS card. It measures the uplink command rate, which is what distinguishes "the video is choppy" from "the robot isn't getting my commands". - Clear both on disconnect so a dead stream cannot show a stale green reading. Body tracking capability detection (bug fix) - Pump sendTrackingStateToServer() while the session is Connecting. The SDK derives body-tracking support from XRSession.enabledFeatures, which it can only read from frames delivered before the stream starts. The render loop previously returned early on state !== Connected, so the SDK never saw such a frame and full-body teleop could silently degrade to hand/controller only despite the client requesting bodyTracking. - Deliberately passes the raw xrFrame rather than trackingFrameAdapter's: during replay the adapter returns a Proxy with a substituted session, and capability detection must reflect the real XRSession. Metrics to the OOB teleop hub - Report all 21 SDK metrics across the render/frame/network cadences, keyed by CloudXR.MetricsName, instead of the previous three. New MetricsAccumulator merges the SDK's partial callbacks so a metric absent from one tick is not reported as zero, and resets between sessions. - oob_teleop_hub.py needs no change: it already stores metrics as an arbitrary {name: value} map per cadence. SDK logs - Mirror SDK log entries to the browser console at matching severity. The onLog/logLevel API existed in 6.2.0; rc2 adds the log content worth surfacing. Pre-stream network test - Wire up the SDK's network test with an in-XR countdown and traffic-light result, defaulting to off: the test holds the session in Connecting for its whole window, and an operator connecting to a robot should not be gated on it. Opt in via the settings panel or ?streamTestMode=warn. - Clamp the configured duration to the [5, 30] second range the SDK accepts, so the on-panel countdown cannot promise a window shorter than the one that runs. - Gate message-channel setup on isConnected, not just a non-null session. Opening a channel sends a control message that requires a connected session, which would fail during the test window and break the teleop control channel. Microphone capture and clientToken/signalingHeaders are available in rc2 but not adopted: the former is an unnecessary permission prompt for robot teleop, and the latter targets Stream Manager auth rather than this direct-connect deployment. Frame-rate negotiation was reviewed and left unchanged: this client already applies the target rate before session creation and passes the effective rate to CloudXR. Also drops the isaac/ requirement from the local-tarball layout check, since that directory is no longer part of the SDK release bundle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> * fix(cloudxr): clear HUD metric cards when the session ends renderFps, poseSendFps and streamingMetrics are module-scoped signals that were never cleared, so after a disconnect the in-XR panel kept drawing the previous session's FPS and latency as if they were live. Same class of staleness the session-quality reset already guarded against, but for the numeric cards. Clears them alongside metricsAccumulator.reset() on Disconnected/Error only, so the 'Testing network' transition into a session is unaffected. The computed texts already fall back to '-' on null, so the cards read as empty rather than zero. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> --------- Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> * Add ESLint and Prettier to the WebXR client (#421) * Add lint config files Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> * Run format Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> --------- Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> Co-authored-by: Yanzi Zhu <yanziz@nvidia.com> --------- Signed-off-by: Yanzi Zhu <yanziz@nvidia.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Gareth Morgan <gmorgan@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Bumps the CloudXR Web SDK from 6.2.0 → 6.3.0-rc2 and adopts the streaming diagnostics it adds.
The bump itself is API-compatible — everything new in rc2 is additive (3
SessionOptionsfields, 3 delegates, 1Sessionmethod, 17MetricsNameentries, a newPerNetworkcadence). The client was built against rc2 with zero code changes first to confirm this, so the version bump could be split out if reviewers prefer.Session quality + Pose Send FPS on the in-XR HUD
MetricsName.SessionQuality(0–4) renders as a 4-bar signal-strength indicator, so an operator sees a degrading link before acting on it rather than inferring it from raw FPS.Body-tracking capability detection — bug fix
The SDK derives body-tracking support from
XRSession.enabledFeatures, which it can only read from frames delivered before the stream starts. The render loop returned early onstate !== Connected, so the SDK never saw such a frame — meaning full-body teleop could silently degrade to hand/controller only despite the client requestingbodyTracking: true.Now pumps
sendTrackingStateToServer()duringConnecting. It deliberately passes the rawxrFramerather thantrackingFrameAdapter's: during replay the adapter returns aProxywith a substituted session, and capability detection must reflect the realXRSession.All SDK metrics to the OOB teleop hub
Reports all 21 metrics across the
render/frame/networkcadences keyed byCloudXR.MetricsName, up from 3. A newMetricsAccumulatormerges the SDK's partial callbacks, so a metric absent from one tick isn't reported downstream as a zero.No change to
oob_teleop_hub.py—_handle_client_metricsalready stores an arbitrary{name: value}map per cadence, so future SDK metrics flow through too. The full metric table is documented inoob_teleop_control.rst.SDK log mirroring
SDK log entries mirror to the browser console at matching severity (
console.error/warn/debug/info) so DevTools filtering works. TheonLog/logLevelAPI existed in 6.2.0; rc2 adds the log content worth surfacing.Pre-stream network test — default off
Wired up with an in-XR countdown and traffic-light result, but off by default: the test holds the session in
Connectingfor its entire window, and an operator connecting to a robot shouldn't be gated on it. Opt in via the settings panel or?streamTestMode=warn.The configured duration is clamped to the [5, 30] second range the SDK accepts, so the on-panel countdown cannot promise a shorter window than the one that actually runs.
Shipped with a required companion fix: message-channel setup is now gated on
isConnected, not just a non-null session. Opening a channel sends a control message that requires a connected session — without this guard, enabling the test would break the teleop control channel.Also
Drops the
isaac/requirement from the local-tarball layout check indownload_cloudxr_sdk.sh— that reference client was removed from the SDK bundle after 6.2.0, so requiring it would reject valid 6.3.0+ tarballs.Type of change
The
onRenderPerformanceMetrics/onStreamingPerformanceMetricsprop signatures onCloudXRComponentchanged from positional numbers to partial objects.CloudXRComponentis internal towebxr_client, so this is not marked breaking — flagging it so reviewers can judge.Testing
Verified locally (macOS, Node 24.11):
The 61 tests include 9 new
MetricsAccumulatortests that pin the wire metric names the hub consumes, since renaming one is a breaking protocol change rather than a refactor.Not verified — needs review attention:
CXR_WEB_SDK_VERSION=6.3.0-rc2NGC download path for the first time; local builds used a supplied tarball.Checklist
SKIP=check-copyright-year pre-commit run --all-filesgit commit -s) per the DCONotes for reviewers
deps/cloudxr/nvidia-cloudxr-6.3.0-rc2.tgzis gitignored (fetched bydownload_cloudxr_sdk.sh);package-lock.jsonis gitignored too, so neither appears in the diff.jest-environment-jsdomas a devDependency — the CloudXR SDK bundle toucheswindowat import time, so the accumulator suite needs it.jest.setup.jsstubs the User Timing entries jsdom lacks.