fix(e2e): treat ERR_PROXY_TUNNEL as proxy wiring success in M12 test#3880
fix(e2e): treat ERR_PROXY_TUNNEL as proxy wiring success in M12 test#3880kagura-agent wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe M12 Telegram reachability test now distinguishes proxy wiring success from upstream proxy policy blocks by treating Node.js ERR_PROXY_TUNNEL errors as PASS outcomes. The test script adds a conditional branch for these proxy-specific errors, and the parity inventory is updated to reflect the new expected passing assertion. ChangesM12 Telegram Reachability Test Refinement
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
✨ Thanks for submitting this detailed PR about treating ERR_PROXY_TUNNEL as proxy wiring success in the M12 test. This PR proposes a way to modify the test-messaging-providers.sh script to recognize ERR_PROXY_TUNNEL as a pass outcome, proving that NemoClaw's proxy integration is functioning correctly. Related open issues: |
The M12 reachability test in test-messaging-providers.sh conflates proxy wiring validation with upstream proxy policy. When a proxy correctly forwards the CONNECT request but the proxy's ACL returns 403 Forbidden, Node.js emits ERR_PROXY_TUNNEL. This proves proxy wiring is correct (traffic routed through the proxy), but the test treated it as a failure because it only recognized HTTP status codes as success and specific network errors as skip-worthy. Add a new branch that recognizes ERR_PROXY_TUNNEL and PROXY_CONNECTION_LOST as proxy-wiring-success outcomes, since they prove Node.js honored the HTTPS_PROXY env var and sent the CONNECT through the configured proxy endpoint. Fixes NVIDIA#3836 Signed-off-by: kagura-agent <kagura.agent.ai@gmail.com>
e824f49 to
a62fab6
Compare
|
Thanks @wscurran for reviewing and linking the related issue! Happy to adjust the approach if needed. |
|
Friendly ping — this has been open for 11 days. Happy to adjust the approach if needed, or I can close it if the timing isn't right. 🙏 |
|
Friendly ping — this PR has been open for 13 days. Let me know if there's anything I should adjust. 🙏 |
|
Closing this — it's been open for 14 days with no review activity. Happy to reopen or submit a fresh PR if there's interest in this approach. Thanks! 🙏 |
Summary
The M12 reachability test in
test-messaging-providers.shconflates proxy wiring validation with upstream proxy policy. When the configured proxy correctly forwards the CONNECT request but returns HTTP 403 (policy deny), Node.js emitsERR_PROXY_TUNNEL. This proves proxy wiring is correct — traffic was routed through the proxy — but the test fell through to thefailbranch because it only recognized:HTTP_*→ passTIMEOUT→ skipECONNRESET|ENETUNREACH|...→ skipERR_PROXY_TUNNELdidn't match any of the skip patterns, so it was treated as a failure even though NemoClaw's proxy integration is functioning correctly.Changes
test/e2e/test-messaging-providers.sh: Add a newelifbranch before the network-error skip that recognizesERR_PROXY_TUNNELandPROXY_CONNECTION_LOSTas pass outcomes, since they prove Node.js honored theHTTPS_PROXYenv var and routed through the configured proxy endpoint.test/e2e/docs/parity-map.yaml: Add the new pass verdict to the M12 parity entries.test/e2e/docs/parity-inventory.generated.json: Add the new pass entry with updated line references.How it works
The fix distinguishes:
ECONNREFUSEDto destination) → still fails as expectedHTTP_200/HTTP_301→ pass (unchanged)ERR_PROXY_TUNNEL→ now passes (was: fail)Closes #3836
Signed-off-by: kagura-agent kagura-agent@users.noreply.github.com
Summary by CodeRabbit