[PR #449] Run network slot setup on the blocking pool #443

New issue

Open

opened 2026-10-29 14:23:28 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-29 14:23:28 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/kvcache-ai/AgentENV/pull/449
Author: @iaroslav-reflection
Created: 10/28/2026
Status: 🔄 Open

Base: main ← Head: network-slot-blocking-pool

📝 Commits (1)

958ca5c fix(sandbox): run network slot allocation and egress policy on the blocking pool

📊 Changes

3 files changed (+253 additions, -16 deletions)

View changed files

📝 src/sandbox/firecracker/sandbox.rs (+66 -15)
📝 src/sandbox/network/manager.rs (+186 -0)
📝 src/sandbox/network/mod.rs (+1 -1)

📄 Description

What

Network slot creation and the egress policy step now run on tokio's blocking pool. This covers both new start and resume. A new SlotLease holds the slot while it moves between tasks. If the task is cancelled or crashes, the lease gives the slot back.

Why

Making a new slot is slow and blocks the thread. It ran on the async workers. When 64 or more sandboxes started at once, all workers were stuck for about 60 s. Guests that were already running timed out.

Starting 128 sandboxes took 28 s with timeouts before. It takes 11 s with no timeouts now.

Changes

Slot creation and the policy step use spawn_blocking.
SlotLease returns the slot to the NetworkManager when it is dropped.
On resume, the policy is still applied before the guest runs.
5 new unit tests: drop, into_inner, unread result, cancelled task, crashed task.
No change to API, config, or storage. To roll back, revert.

Not included

update_network_policy on a running sandbox still runs on the async worker.
The warm-pool size setting.

Risks

If a policy install fails, the slot may go back to the warm pool with part of the rules. This already happens today. It needs its own fix.
New slots now wait in the blocking pool queue. There is no limit on how many run at once. I did not measure the wait under mixed load.

Testing

cargo fmt and cargo clippy -D warnings pass.
cargo test -p agentenv --lib -- network::manager: 31 passed, 1 ignored.
Integration tests need root and /dev/kvm, so CI will run them.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/kvcache-ai/AgentENV/pull/449 **Author:** [@iaroslav-reflection](https://github.com/iaroslav-reflection) **Created:** 10/28/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `network-slot-blocking-pool` --- ### 📝 Commits (1) - [`958ca5c`](https://github.com/kvcache-ai/AgentENV/commit/958ca5c8ba361c52b44db3418193eddb34bc0301) fix(sandbox): run network slot allocation and egress policy on the blocking pool ### 📊 Changes **3 files changed** (+253 additions, -16 deletions) <details> <summary>View changed files</summary> 📝 `src/sandbox/firecracker/sandbox.rs` (+66 -15) 📝 `src/sandbox/network/manager.rs` (+186 -0) 📝 `src/sandbox/network/mod.rs` (+1 -1) </details> ### 📄 Description ## What Network slot creation and the egress policy step now run on tokio's blocking pool. This covers both new start and resume. A new `SlotLease` holds the slot while it moves between tasks. If the task is cancelled or crashes, the lease gives the slot back. ## Why Making a new slot is slow and blocks the thread. It ran on the async workers. When 64 or more sandboxes started at once, all workers were stuck for about 60 s. Guests that were already running timed out. Starting 128 sandboxes took 28 s with timeouts before. It takes 11 s with no timeouts now. ## Changes - Slot creation and the policy step use `spawn_blocking`. - `SlotLease` returns the slot to the `NetworkManager` when it is dropped. - On resume, the policy is still applied before the guest runs. - 5 new unit tests: drop, `into_inner`, unread result, cancelled task, crashed task. - No change to API, config, or storage. To roll back, revert. ## Not included - `update_network_policy` on a running sandbox still runs on the async worker. - The warm-pool size setting. ## Risks - If a policy install fails, the slot may go back to the warm pool with part of the rules. This already happens today. It needs its own fix. - New slots now wait in the blocking pool queue. There is no limit on how many run at once. I did not measure the wait under mixed load. ## Testing - `cargo fmt` and `cargo clippy -D warnings` pass. - `cargo test -p agentenv --lib -- network::manager`: 31 passed, 1 ignored. - Integration tests need root and `/dev/kvm`, so CI will run them. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-29 14:23:28 +00:00