[letv1nnn]

Summary

The sandbox network broker logged every nonblocking loopback connect that returned EINPROGRESS as WARN ... sandbox network notification denied. EINPROGRESS is the normal result of a nonblocking connect, not a denial. Node.js workloads produced about 10 of these warnings per second, which hid real denials. The broker now sends EINPROGRESS to the workload directly, so it no longer logs a denial. The workload sees no change.

Related Issue

Closes #5130

Changes

• connect_local_tcp in crates/openshell-sandbox/src/network_broker.rs: when a nonblocking loopback connect returns EINPROGRESS, reply with respond_errno(EINPROGRESS) and return Ok(()). The blocking branch already answers this way. The error is no longer passed to the dispatcher, which logs every handler error as a denial. Real connect failures such as ECONNREFUSED are logged as before.
• New test nonblocking_loopback_connect_completes_after_in_progress: a nonblocking loopback connect from a mediated workload gets EINPROGRESS, becomes writable with SO_ERROR clear, gets EISCONN on a repeated connect, and delivers data to the peer.

Not in scope:

• The dispatcher still labels other normal socket results (ECONNREFUSED, EISCONN, EAGAIN) as "denied". That could be a follow-up.
• bug(sandbox): mediated nonblocking TCP connect returns 0 instead of EINPROGRESS, breaking Microsoft.Data.SqlClient #4980: if that fix returns EINPROGRESS from the external connect path, it should answer the workload directly the same way, or the warning will return for external connections.

Testing

• Checks appropriate to the affected code and behavior pass
• Unit tests added/updated (if applicable)
• E2E tests added/updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[TaylorMutch]

Accepted #5130. The production change looks sound: replying with EINPROGRESS directly preserves the workload's errno while keeping a normal nonblocking connect out of the dispatcher's denial-warning path. Other connect errors and notification-response failures still propagate.

Please strengthen the regression coverage before merge. nonblocking_loopback_connect_completes_after_in_progress checks connection behavior that already works before this fix; it never asserts that the false warning disappears, so it does not distinguish the original bug from the corrected behavior. Add a focused test with scoped tracing capture that exercises the notification handling path and verifies that EINPROGRESS reaches the workload without a WARN denial. Also verify that an actual connect failure still reaches the existing warning/error-response path. The logging assertion should fail without the production change and pass with it.

Local verification: the patch applies cleanly to main at 00f7ba72b. Five isolated response-path checks using the original/proposed match expressions and a fake notification listener passed, covering progress routing, immediate success, other errors, and reply failure. Native Linux seccomp tests were not run on this macOS host.

[letv1nnn]

thanks for the review! I dropped the old completion test and added a small tracing layer that captures the broker's denial warnings, plus two tests, one shows an in-progress connect no longer logs a false WARN (it fails without the fix), and one shows a real connect failure (ENETUNREACH) still does.

[TaylorMutch]

/ok to test 10538e1

[TaylorMutch]

@letv1nnn the PR fails branch checks, please address it.