Migrating to v0.24

v0.24.0 changed resource ownership and failure reporting. Applications upgrading from v0.23 should review their shutdown paths, even when provider calls succeed.

Close resources explicitly

Low-level ParallelBatchProcessor.process_all() leaves the artifact store open until processor shutdown. Use an async context manager or call shutdown() in finally. Convenience APIs manage their own lifetime. Cleanup failures can now propagate from context exit; a successful batch does not imply successful cleanup.

Runtime, admission, strategy, and store cleanup run in dependency order. Live synchronous progress or post-processing callbacks are barriers: cleanup waits for their threads before closing dependent resources. There is no global cleanup timeout. Ensure application callbacks can finish or cooperate with shutdown.

The first cancellation of a closer is deferred until teardown finishes, then re-raised. A second cancellation force-aborts cleanup and skips dependent resources, sacrificing durability. A private cleanup interruption raises CleanupInterruptedError; a later explicit close retries unfinished steps. Successful steps are not repeated. User cleanup hooks must tolerate partial work from an earlier failed invocation.

Handle interruption and cleanup failures

BatchInterruptedError reports workers stopping before a batch queue drains. StreamFinalizationError reports cancellation of the private stream finalizer; it does not mean the consumer was cancelled. Streams retain their failure terminal, including after a later successful explicit close. Automatic context exit reports an existing failed finalization without silently retrying it.

A body exception or caller cancellation takes precedence over ordinary cleanup failures. Runtime and store cleanup failures propagate when no primary failure exists. High-level convenience APIs preserve a completed result when only user strategy cleanup fails; explicit close still reports cleanup failures. See the cleanup contract for the complete precedence and cancellation rules and their executable tests.

Middleware and replay

before_process runs once per logical item, before artifact lookup and strategy preparation, inside the total item deadline. Retries reuse its effective request. Replacement items preserve accepted identity and submission order. Version application/parser identity when hook behavior changes: replay preserves the historical post-after_process output and does not rerun that hook.

v0.24.1 corrections

v0.24.1 fixes usage accounting, quota-scope errors, category-driven retry delay, and DeepSeek Responses compatibility. These corrections are separate from the v0.24.0 lifecycle changes. See the roadmap and changelog for release status. No further lifecycle rewrite is part of it.