Table of Contents
🌏 中文版
A tool call passing path, permission, and OS sandbox checks does not imply that multiple calls can run concurrently. Rivumi separates eligible read batching, bounded read-only programs, and file-backed transactions.
Concurrency requires three matching signals
AgentRunner._can_execute_concurrently() requires a definition marked both read-only and concurrency-safe, plus a runtime effect classified as READ. Only then does a batch use asyncio.gather. Batch lifecycle events are recorded, while observations retain request order. Modify, execute, and transaction calls remain sequential, and repeated-action guards still count batched calls.
Programs are bounded read-only control flow
tool_program permits list, read, search, and git diff operations. It supports positive bounded repeats and if_contains branches, with a maximum nesting depth of three and a cap on expanded steps. The harness owns the timeout.
The program is read-only but the composite tool itself is intentionally not concurrency-safe: later steps and branches depend on earlier observations.
Transactions compensate workspace-file changes
tool_transaction sequences read, replace, patch, check, and diff steps. Before execution, it conservatively unions paths that either branch could touch and snapshots bytes, mode, and prior existence. On failure it restores existing files and removes files created by the transaction. A rollback failure is reported separately rather than hidden.
This is atomic-ish only for the tracked workspace files. Rivumi cannot undo processes, database writes, network requests, emails, remote APIs, or other command side effects. Checks should therefore remain checks rather than hidden deployment steps. The next article shows how these operations are recorded for replay and review.
References
Loading...