[maia-andre]

Resolves: #8803

📝 Summary

With rejection_behavior = continue, SignatureRejectionService::persistRejection() releases the next signing order of every document the rejection closes, inside one transaction. SequentialSigningService::releaseNextOrder() notified each released signer immediately, so if a later document of an envelope failed and the transaction rolled back, the signer had already received a "ready to sign" notification for an activation that no longer existed.

This PR separates the state change from the notification:

• SequentialSigningService::activateNextOrder() sets the next order to ABLE_TO_SIGN and returns the activated signers without notifying them.
• SequentialSigningService::notifyActivatedSigners() sends the notifications. This is the code that used to live inside activateSignersForOrder().
• releaseNextOrder() calls both, so the non-transactional callers in SignFileService and reorderAfterDeletion() behave as before.
• SignatureRejectionService collects the released signers inside the transaction and notifies them only after commit(). On rollback, nobody is notified.

A notification that fails after the commit is logged and does not turn the recorded rejection into an error for the signer. This follows the same reasoning already used for SignatureRejectedEvent.

Composition: +79/−26 lines of production code in two files, +136/−6 lines of tests. Start with SequentialSigningService.php.

🧪 How to test

composer test:unit -- --filter SequentialSigningServiceTest
composer test:unit -- --filter SignatureRejectionServiceTest

New tests:

• SequentialSigningServiceTest: activation does not notify and returns the activated signers; a parallel flow activates nobody; every identify method of every signer is notified.
• SignatureRejectionServiceTest: the order is activate → commit → notify; an envelope with two documents where the second fails rolls back and notifies nobody; a failing notification after the commit keeps the rejection.

I also ran the other service tests that use SequentialSigningService (RequestSignatureService, SignFileService, SignRequest/*, SignerValidator) and the whole SignatureRejection directory. Psalm and php-cs-fixer report nothing on the changed files.

⚙️ API / Back‑end changes

• Notifications for signers released by a rejection are sent only after the rejection transaction commits
• Unit and/or integration tests added – required for backend changes

No Behat scenario was added: the issue asks for the test at the service/event boundary, and the existing continue scenario in sign/reject.feature uses a parallel flow, which does not release a next order.

✅ Checklist

• I have read and followed the contribution guide.

🤖 AI (if applicable)

• The content of this PR was partially or fully generated using AI

[YvesCesar]

Many thanks, @maia-andre !

I added a comment for review.

[maia-andre]

Thanks for reconciling this, @vitormattos, and for keeping me as co-author on a800b90.

I compared this branch with main (after #8912) plus #9041, test by test. Everything here is now covered:

Here	main + #9041
testSignersReleasedByARejectionAreNotifiedOnlyAfterTheCommit	testTheReleasedOrderIsNotifiedOnlyAfterTheRejectionIsCommitted
testTheRejectionEventIsDispatchedBeforeTheReleasedSignersAreNotified	same test (asserts commit → event → notification)
testARolledBackRejectionNotifiesNobodyItHadReleased	testARolledBackRejectionDoesNotNotifyAnOrderReleasedForAnEarlierDocument
testAnErrorWhileNotifyingAfterTheCommitIsNotHidden	testAnUnexpectedNotificationExceptionDoesNotRollBackACommittedRejection, testAProgrammingErrorWhileNotifyingIsNotConvertedIntoADeliveryFailure
testAFailedIdentifyMethodLookupDoesNotStopTheOtherActivatedSigners	testNotifyActivatedSignersContinuesAfterAnIdentificationLookupFails
testAFailedNotificationDoesNotStopTheOtherActivatedSigners	testNotifyActivatedSignersKeepsNotifyingTheRemainingSignersWhenADeliveryFails
testAProgrammingErrorWhileNotifyingIsNotHidden	testNotifyActivatedSignersDoesNotSwallowProgrammingErrors

The three points @YvesCesar raised are also in main: the identify-method lookup is inside a try, SignatureRejectedEvent is dispatched before notifyActivatedSigners(), and a failed lookup is tested.

So nothing from this PR is left outside #9041. Unless you see something I missed, I'd close this one in favor of #9041. Should I close it now, or wait until #9041 is merged?

[maia-andre]

@vitormattos a gentle follow-up on the question above: #9041 still covers everything from this PR. Should I close this one now, or wait until #9041 is merged? Once this is settled I'll push the second part of #8915, which builds on it.