Rework barrier release to be a two-step process

[pencil]

This pull request refactors the AtMostOnceBarrier logic to improve reliability when scheduling workflow completion callbacks. The core change is to separate the confirmation of barrier release from the initial barrier wait, ensuring that expensive workflow deserialization succeeds before marking the barrier as released. This decreases the risk of missed callback executions if a worker crashes during deserialization.

[macroscopeapp]

Rework barrier release to a two-step process by adding AtMostOnceBarrier.confirm_release in dramatiq_workflow/_barrier.py and updating WorkflowMiddleware._process_completion_callbacks in dramatiq_workflow/_middleware.py

Introduce a two-step barrier release: record completion via AtMostOnceBarrier.confirm_release and run callbacks after confirmation, with middleware deferring confirmation until after workflow unserialization.

• Add AtMostOnceBarrier.confirm_release in dramatiq_workflow/_barrier.py to gate once-only release and remove the class wait override
• Update WorkflowMiddleware._process_completion_callbacks in dramatiq_workflow/_middleware.py to call confirm_release after unserialize_workflow and skip callbacks on falsy confirmation
• Update tests in dramatiq_workflow/tests/test_barrier.py and dramatiq_workflow/tests/test_middleware.py to assert new confirmation flow

📍Where to Start

Start with the WorkflowMiddleware._process_completion_callbacks handler in dramatiq_workflow/_middleware.py, then review AtMostOnceBarrier.confirm_release in dramatiq_workflow/_barrier.py.

---

Macroscope summarized 2c529a5.

[dan-woz]

Gonna chuckle if this is the problem. Deserialization: free until it's not 😔