[ravi-pplx]

Summary

Add idempotent ExecutionService::close() to refuse new calls and cancel admitted work without cancelling the caller's token. Share the closure check across process, filesystem and environment operations. This PR's close is abortive; #827 adds graceful closure and bounded drain. Clarify that request cancellation can receive grace, while service cancellation can terminate identity workers immediately.

Stacked on #740; follows the embedding RFC. Active-service daemon behavior and wire contracts are unchanged.

Validation

418 affected tests passed on the rebased stack, including five privileged probes. Formatting, affected all-feature/no-default-feature Clippy and doctests passed on Linux. Native macOS and Kind/Firecracker were not rerun locally; CI is pending on this head.

Severity and risk

Moderate: shutdown needs consistent admission closure. Embedding callers must handle the new result from environment configuration. Direct I/O cleanup can outlast cancellation grace. Revert with dependent changes to roll back.

AI assistance: Codex contributed code, tests and this description.

[zibi-pplx]

Thanks for ac9bc093. Owning a child of the supplied token fixes the issue I was going to raise, that close() would cancel the caller's token, and the new assertions cover it. The entry-point checks and waking uploads that are waiting for Open look good, and the biased select is cancellation-safe.

Requesting changes for one remaining lifecycle issue (inline): close() still aborts work that was already admitted, while the docs say it "may still finish". Non-blocking: require_running is duplicated, and configure_process_env could use a typed error (both inline). The same Kind/Firecracker CI note as #702 applies.

Review prepared with AI assistance (Claude Code); findings checked against the PR head.

[cla-assistant]

All committers have signed the CLA.

[zibi-pplx]

Follow-up review at 7c632eb124ab, including the graceful-close/drain implementation in #827.

The earlier caller-token isolation, duplicated admission check, and explanation for returning Status from environment configuration are addressed. #827 supplies the separate admission-only close() and abortive cancel(), so I am not repeating the superseded graceful-close request here.

[P2, documentation] The advertised worker cancellation grace does not apply to service shutdown.

The close() documentation and README say supervised mutations can finish during cancellation_grace, after which identity workers are terminated. However, each worker's stop_token is a child of the pool/service shutdown token, and supervise_worker calls child.kill().await as soon as it is cancelled. An in-flight batch or rename can therefore lose its worker immediately and produce an unknown outcome; it does not receive the stated grace.

Please distinguish request cancellation, which can receive the supervisor grace, from service/parent cancellation, which can kill workers immediately. The same distinction needs to carry into #827's README, because drain-deadline expiry requests service cancellation too. Correcting the documentation preserves the current abortive behavior; changing token ownership would be a separate shutdown-policy change.

This worker-kill behavior predates the stack; the issue here is the new public promise.

Codex-assisted follow-up review, verified by tracing cancellation from the service through the pool to the worker supervisor.