Embed CloudXRLauncher lifecycle inside TeleopSession
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 52/100
Hướng nghiên cứu
Bắt đầu với các entry point TeleopSession và CloudXRLauncher, đồng thời kiểm tra các context manager lồng nhau của ví dụ mcap hiện có. Theo dõi thứ tự khởi động, lỗi kết nối và teardown, sau đó bổ sung coverage cho thấy ownership nội bộ, tùy chọn opt-out đối với launcher bên ngoài và việc cleanup sạch sẽ khi xảy ra lỗi; ví dụ mcap hiện có vẫn phải hoạt động.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Embed CloudXRLauncher lifecycle inside TeleopSession
Context
In the live teleop path, users currently have to set up the CloudXR runtime
launcher and the teleop session as two separate context managers:
```python
with launcher_ctx as launcher:
if launcher is not None:
print(f"[live] CloudXR runtime started (WSS log: {launcher.wss_log_path})")
print("[live] waiting for headset connection… (Ctrl+C to stop)")
with TeleopSession(config) as session:
...
```
This was raised in review on the mcap-example PR (@aristarkhovNV): the nested
launcher context is extra plumbing the caller shouldn't have to wire up by hand.
Deferring it out of that PR to keep its scope on the mcap example only.
Proposal
Have TeleopSession optionally own the CloudXRLauncher lifecycle so the
common case collapses to a single context manager:
python with TeleopSession(config) as session: ...
TeleopSession.__enter__ would start the launcher (when configured for the
live/CloudXR path) and __exit__ would tear it down, surfacing wss_log_path
and any launcher state via the session object.
Motivation
- Removes boilerplate and the nested
withfrom every caller. - Single ownership point for startup/teardown ordering (launcher must come up
before the session connects, and tear down after). - Centralizes the
launcher is not Noneguard instead of leaking it to callers.
Open questions / considerations
- Opt-out path: keep the ability to inject an externally-managed launcher
(e.g. passlauncher=...ormanage_launcher=False) for callers that need to
share one launcher across sessions or control its lifecycle themselves. - Backward compatibility: does anything depend on the current two-context
shape? If so, keep the standalone launcher context working. - Failure semantics: if the launcher starts but the session fails to
connect, ensure the launcher is cleanly torn down (no orphaned runtime). - Logging: preserve the
[live] CloudXR runtime started (WSS log: …)and
"waiting for headset connection" messages, moved inside the session.
Acceptance criteria
-
TeleopSessioncan start/stop the CloudXR launcher internally when configured. - Single
with TeleopSession(config)works for the live path. - An escape hatch exists for an externally-managed launcher.
- Startup/teardown ordering and failure cleanup are covered by a test.
- Existing mcap example still works.
- Ngôn ngữ chính
- Python
- Star
- 412
- Fork
- 97
- Merge trung bình
- 2 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 141
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của NVIDIA/IsaacCapture
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
NVIDIA/IsaacCapture#910 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
NVIDIA/IsaacCapture#891 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
NVIDIA/IsaacCapture#1319 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add OneRobotics A1 asset and Isaac Teleop exampleCó thể đã có người làm @WangXuechun-woan đã nhận 5 ngày trước. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
NVIDIA/IsaacCapture#1291 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
NVIDIA/IsaacCapture#1217 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của NVIDIA/IsaacCapture
Issue tương tự
-
The changelog workflow excludes otelbot but not dependabot, so every Dependabot pull request fails the changelog checkCó thể đã có người làm @ocelotl đã nhận hôm nay. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
open-telemetry/opentelemetry-python#5825 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
cuga-project/cuga-agent#1020 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 70/100
microsoft/playwright#43640 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
stac-utils/stac-fastapi-elasticsearch-opensearch#965 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
from-review-extraction library privacy python severity:suggested
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
LearningCircuit/local-deep-research#7951 ·
Maintainer thường phản hồi trong vòng 2 ngày