test(e2e): revert failing #2701 guard assertion

[sandl99]

Summary

Remove the newly added #2701 failing-test-first assertion from the legacy crash-loop E2E so the scheduled suite no longer fails on the known missing guard-chain recovery bug. The #2478 warning check remains in place, so this only backs out the new guard that is currently red.

Related Issue

Refs #2701. Reverts the failing assertion added by #5049.

FYI @jyaunches: this new guard is failing in today's scheduled run with FAIL: #2701: recovery did NOT restore guard chain — gateway respawned naked (DGX Spark crash-loop scenario). This PR removes only that assertion while preserving the existing #2478 recovery-warning coverage.

Changes

• Remove the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 gateway_guards_active failure block from test/e2e/test-issue-2478-crash-loop-recovery.sh.
• Keep the existing Phase 4 negative-case warning assertion and recovery/restore flow unchanged.
• Triggered a full E2E / Nightly run against commit a705c89d5e35ffacd81c2f813dcbd3ebca82df96: https://github.com/NVIDIA/NemoClaw/actions/runs/27396406250

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Verification

Ran bash -n test/e2e/test-issue-2478-crash-loop-recovery.sh; commit/push hooks also passed for the touched file. Full E2E is currently running at https://github.com/NVIDIA/NemoClaw/actions/runs/27396406250.

• npx prek run --all-files passes
• npm test passes
• Tests added or updated for new or changed behavior
• No secrets, API keys, or credentials committed
• Docs updated for user-facing behavior changes
• npm run docs builds without warnings (doc changes only)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: San Dang sdang@nvidia.com

Summary by CodeRabbit

• Tests
  • Simplified crash-loop recovery regression test by removing an intermediate validation assertion, streamlining the test flow to focus on recovery and stability phases.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: fdf981de-622d-40f6-89fc-98f424a10a7c

📥 Commits

Reviewing files that changed from the base of the PR and between b3500bf and a705c89.

📒 Files selected for processing (1)

• test/e2e/test-issue-2478-crash-loop-recovery.sh

💤 Files with no reviewable changes (1)

• test/e2e/test-issue-2478-crash-loop-recovery.sh

---

📝 Walkthrough

Walkthrough

The e2e regression script removes a post-negative-case assertion that verified the respawned gateway maintained the library guard chain active. After waiting for the negative process, the test now proceeds directly to proxy-env restoration without performing that intermediate guard-chain validation.

Changes

E2E Crash Loop Recovery Test

Layer / File(s)	Summary
Remove post-negative-case guard assertion test/e2e/test-issue-2478-crash-loop-recovery.sh	The #2701 assertion checking gateway_guards_active "$NEGATIVE_PID" after negative-case recovery is removed, streamlining the test flow to proceed directly to proxy-env restoration and the guard-restore recovery phase.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related issues

• nightly-e2e: gateway recovery does not regenerate proxy-env.sh guard chain (#2701) #5262 — The removed assertion directly checks for the proxy-env/library guard chain regeneration issue that #5262 documents, indicating this test change addresses the same underlying problem.

Suggested labels

nightly-e2e

Suggested reviewers

• cv

Poem

🐰 An assertion departs with grace,
No guard-chain check in this test case,
The gateway recovers without the stare,
Straight to restore—a simpler affair! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'test(e2e): revert failing #2701 guard assertion' clearly and specifically describes the main change: removing a failing assertion from an e2e test script.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch revert/2701-crash-loop-e2e-guard

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

E2E Advisor Recommendation

Required E2E: None
Optional E2E: issue-2478-crash-loop-recovery-e2e, gateway-guard-recovery

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• None. No merge-blocking E2E is required because this PR changes only an existing E2E test script and cannot affect runtime/user flows directly. Optional runs may be useful to validate the edited test and adjacent guard-recovery coverage.

Optional E2E

• issue-2478-crash-loop-recovery-e2e (medium): Optional validation that the edited shell E2E still runs and that the remaining issue-2478 recovery, warning, restore, and soak phases are syntactically and behaviorally intact.
• gateway-guard-recovery (medium): Optional confidence check for the removed [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-chain assertion area; this existing Vitest job is the dedicated gateway guard recovery coverage.

New E2E recommendations

• None.

[github-actions]

Vitest E2E Scenario Recommendation

Required Vitest E2E scenarios: None
Optional Vitest E2E scenarios: None

Workflow run

Full Vitest E2E advisor summary

Vitest E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required Vitest E2E scenarios

• None. Changed file is a legacy test/e2e shell test outside test/e2e-scenario/ and does not affect the Vitest scenario registry, live support, fixtures, manifests, or e2e-vitest-scenarios.yaml dispatch machinery.

Optional Vitest E2E scenarios

• None.

Relevant changed files

• None.

[github-actions]

PR Review Advisor

Findings: 0 needs attention, 2 worth checking, 0 nice ideas
Top item: Update #2701 coverage ownership after removing the legacy assertion

Review findings

🛠️ Needs attention

• None.

🔎 Worth checking

• Source-of-truth review needed: Legacy crash-loop E2E Phase 4 / [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-chain recovery coverage: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: This PR removes the legacy [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 `gateway_guards_active "$NEGATIVE_PID"` assertion. The Vitest scenario still documents that the legacy bash Phase 4 contains both the [DGX Spark] Gateway crash loop on startup: @homebridge/ciao networkInterfaces() returns EPERM in OpenShell sandbox #2478 WARNING assertion and the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-chain assertion, which is no longer true.
• Update [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 coverage ownership after removing the legacy assertion (test/e2e/test-issue-2478-crash-loop-recovery.sh:510): This PR removes the legacy bash assertion that recovery restores the guard chain after `/tmp/nemoclaw-proxy-env.sh` is missing. Nearby Vitest coverage appears to own that contract now, but `test/e2e-scenario/live/gateway-guard-recovery.test.ts` still states that the legacy bash Phase 4 retains both the [DGX Spark] Gateway crash loop on startup: @homebridge/ciao networkInterfaces() returns EPERM in OpenShell sandbox #2478 WARNING assertion and the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-chain assertion. That stale source-of-truth creates a security-testing/holistic-posture risk in a sandbox recovery path: future maintainers may believe this legacy scheduled E2E still catches a guardless recovery regression when it no longer does.
  • Recommendation: In this PR, update the coverage note/source-of-truth: either add a short comment in the legacy bash Phase 4 saying the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-restoration contract is owned by the Vitest `gateway-guard-recovery` scenario, or update the Vitest comment that currently says the legacy bash phase still contains the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 assertion.
  • Evidence: Deleted block asserted `gateway_guards_active "$NEGATIVE_PID"` and failed with `[DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701: recovery did NOT restore guard chain`. The remaining Phase 4 keeps only the `[gateway-recovery] WARNING` check and restore/soak flow. Nearby `test/e2e-scenario/live/gateway-guard-recovery.test.ts` asserts `gateway.expectGuardChainActive(instance)` after wipe/kill/recovery, but its header comment says the legacy bash phase remains with both assertions.

🌱 Nice ideas

• None.

Consider writing more tests for

• **Update [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 coverage ownership after removing the legacy assertion** — In this PR, update the coverage note/source-of-truth: either add a short comment in the legacy bash Phase 4 saying the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-restoration contract is owned by the Vitest `gateway-guard-recovery` scenario, or update the Vitest comment that currently says the legacy bash phase still contains the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 assertion.
• **Acceptance clause:** Onboard finishes successfully. `nemoclaw <name> status` initially shows everything green. But the gateway never actually serves anything. Messages to the Telegram bot get no reply. — add test evidence or identify existing coverage. This PR does not change runtime recovery behavior. Existing script coverage still checks initial gateway readiness and `gateway_serves_inference`; the removed assertion only affected the later missing-guard negative path.
• **Acceptance clause:** `connect` doesn't auto-recover, because the respawned gateway hits the same crash on the same line every time. — add test evidence or identify existing coverage. The legacy script still exercises the production `nemoclaw <name> connect --probe-only` recovery path in normal crash cycles and in Phase 4, but this PR removes one assertion about guard restoration after `/tmp` guard loss.
• **Acceptance clause:** `@homebridge/ciao` (the mDNS/Bonjour library OpenClaw bundles for local network discovery) calls `os.networkInterfaces()` during init. Inside the OpenShell sandbox the underlying syscall fails with EPERM, because seccomp is blocking the netlink socket family. — add test evidence or identify existing coverage. No product code changes address the root cause. Existing guard-chain checks still look for ciao/safety-net markers in normal and restored flows; the removed [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 assertion was specific to missing `/tmp/nemoclaw-proxy-env.sh` recovery.
• **Acceptance clause:** 1. Wrap the ciao NetworkManager calls in try/catch inside OpenClaw, fall back to no mDNS if `os.networkInterfaces()` throws. Probably the smallest diff. — add test evidence or identify existing coverage. This PR is test-only and does not modify OpenClaw ciao handling.
• **Acceptance clause:** 2. Add an `OPENCLAW_DISABLE_MDNS=1` env var (or a config flag) that skips loading ciao entirely. Most explicit user-facing fix. — add test evidence or identify existing coverage. This PR is test-only and does not add an mDNS configuration flag.
• **Legacy crash-loop E2E Phase 4 / [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-chain recovery coverage** — The apparent authoritative regression test is `test/e2e-scenario/live/gateway-guard-recovery.test.ts`, which wipes the guard chain, kills the gateway tree, runs `connect --probe-only`, expects the guard chain to be active, expects no recovery WARNING, and checks PID stability.. This PR removes the legacy [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 `gateway_guards_active "$NEGATIVE_PID"` assertion. The Vitest scenario still documents that the legacy bash Phase 4 contains both the [DGX Spark] Gateway crash loop on startup: @homebridge/ciao networkInterfaces() returns EPERM in OpenShell sandbox #2478 WARNING assertion and the [DGX Spark] Host reboot bricks sandbox until 5-min rebuild --yes: connect recovery path warns about missing /tmp guards but launches gateway naked → @homebridge/ciao crash loop #2701 guard-chain assertion, which is no longer true.

Workflow run details

This is an automated advisory review. A human maintainer must make the final merge decision.