- Shipped
- August 6, 2026 at 5:11 PM UTC
- Author
- Kamo
- Commit
- 60967b4
Redeliver published the new version row, flipped every OPEN assignment to SUPERSEDED, and submitted the reissue from inside that same uncommitted transaction. The worker runs on a pool thread in its OWN transaction, so it saw none of it: findById(versionUid) came back empty and it reissued nothing, having already superseded everybody's in-progress work. Win the race instead and it is no better -- the already-assigned re-check still sees the pre-supersede rows and skips every member. A second Redeliver then 409s "nothing has changed", so there was no obvious way back. LegalAfterCommit is now the single hand-off: it registers an afterCommit synchronization when one is active and runs the action immediately when there is none. dispatch() takes an explicit deferToCommit. Redeliver passes true. Deliver passes FALSE on purpose -- it is readOnly, writes nothing, and its inline submit is what lets a full queue answer a truthful 503 rather than an optimistic 200. The envelope-void batch goes through the same gate: queued before commit, a serialization retry left envelopes cancelled upstream with their assignments still OPEN. Also: - Void resolved outcome names through the unscoped MemberRepository using caller-supplied ids, so a NOT_FOUND answered ANOTHER ORG'S member name to whoever guessed the id. Names now come only from the org-scoped rows. - A FAILED envelope void was log-only while the assignment was already VOIDED and the upstream envelope stayed live and signable. Bounded retry, then an ERROR naming each envelope that is still live. - Redeliver had no ARCHIVED check at all and would publish a version of a retired template and supersede against it. - A signable row stranded with a null envelope_uid could never be cleared: the subtraction that correctly refuses a second legal instrument also refused to look at the first one. Plan carries repairTargets and the worker re-mints those envelopes, so re-running Deliver is the repair path. Worker failures are in the run summary, which is the only place they can surface. - A legal package sends exactly one signer, but ESigService now WARNS on under-supply instead of 400ing, so a template with an employer countersign slot would flatten with that block blank. LegalSignerSlotGuard refuses a multi-slot template at publish and again at delivery. - The audience preview listed every active member with their email in one response. The list is capped at 500; every count still covers the whole resolution, because the confirmation dialog reconciles against Deliver's. - deliverableCheck re-ran requireDeliverableVersion, so every Deliver walked the **************** ladder twice for one answer. 107 -> 139 tests, 0 failures. No schema change.