[Nir-Az]

@
TL;DR: Flip the default of partial-device-allowed from false to true in the three places its read. With the watcher-level HID-binding deferral from #15058 (5 s MAX_DEFERRAL) in place, partial enumeration is the rare slow-HID corner case rather than the common path — surfacing the partial device and letting the supersede event upgrade it ~3 s later is a better UX than rejecting it outright and showing "no device" for that window.

Changes

Three one-line flips, no logic changes:

File	Line	Effect
src/ds/ds-private.cpp	is_partial_device_allowed() fallback false→true	SDK D400/D500 USB factory default
src/dds/rsdds-device-factory.cpp	watcher singleton partial_capabilities_allowed fallback false→true	DDS factory default
common/viewer.cpp	"Allow partial device initialization" checkbox initial state false→true	Viewer UI default for fresh users

Aligning all three keeps UI and SDK behavior coherent: fresh users see a checked box and the SDK behaves as the box says.

Existing-user behavior

Users who have already toggled the checkbox have context.partial-device-allowed written in their realsense-config.json — the SDK reads that explicit value and the new defaults dont apply to them.

Verification

Hot-plug stress on D455 via Acroname hub, 10 iterations (partial-device-allowed: true, observing both added events per cycle):

Outcome	Count
Full from first event (HID bound within 5 s)	8/10
Partial → full supersede (~3 s gap)	2/10
Partial only (no supersede)	0/10
No device	0/10

With the new default, the 2/10 slow-HID cases produce a brief no-IMU window that auto-recovers, instead of a 3–4 s "device not found" gap under the old default.

Test plan

• Build clean on Windows VS 2022 (verified locally on combined branch with ds: honor partial-device-allowed setting for d400/d500 USB enumeration #15057+mf-backend: defer device-watcher callback until HID Sensor binding completes #15058)
• Smoke that explicitly setting "partial-device-allowed": false in context JSON still rejects partials
• CI: libci pipeline
  @

[Nir-Az]

rs-agentic bot automated review

Summary of findings (3 inline comments below):

1. 🐛 Inconsistent default in constructor — the class-level default parameter () was not updated alongside the call-site default.
2. ⚠️ Silent partial-device exposure — SDK consumers that don't set the flag explicitly will now silently receive partial devices (e.g., no IMU). No public API/changelog note.
3. 🧪 No unit tests — no automated test for the new default or for ensuring partial-device-allowed: false still rejects partials.
4. 📝 Missing newline at EOF in src/ds/ds-private.cpp (pre-existing, but could be fixed in this PR).
5. 🔗 Undeclared dependency on PR #15058 — the PR body mentions MAX_DEFERRAL from #15058 as a prerequisite; consider adding a hard dependency or merge order note.

This comment was auto-generated by the rs-agentic bot

[Nir-Az]

🧪 Missing Test Coverage — rs-agentic bot

This PR changes a behavioural default that affects all SDK consumers and the Viewer, but no automated tests are added or updated.

Specifically, the test plan checks (in the PR body) are all manual:

• ✅ Build clean on Windows VS 2022
• ✅ Smoke partial-device-allowed: false still rejects
• ✅ CI: libci pipeline

Suggested automated tests (aligned with the existing pytest / unit-tests/dds/ framework):

Test	Location	What to assert
test-partial-default-true	unit-tests/dds/	rsdds_device_factory reads partial-device-allowed with default true when settings key is absent
test-partial-override-false	unit-tests/dds/	Passing {"partial-device-allowed": false} in context settings still rejects partial device
test-ds-partial-default-true	unit-tests/	is_partial_device_allowed(ctx) returns true when no key is present in context settings

Without regression tests, a future change that accidentally reverts the default back to false will not be caught by CI.

---

🔗 Merge-order dependency on PR #15058

The PR description correctly states that this change "relies on the watcher-level HID-binding deferral from #15058 (5 s MAX_DEFERRAL)". Without #15058 merged first, the partial→full supersede path will not work and the 2/10 slow-HID cases described in the verification table will produce a permanent partial device (no IMU, no auto-recovery).

Suggestion: Either:

• Block this PR on mf-backend: defer device-watcher callback until HID Sensor binding completes #15058 (add Blocked by #15058 to the PR description), or
• Merge both in the same batch (ensure CI runs with both changes combined).

This comment was auto-generated by the rs-agentic bot