- Shipped
- August 6, 2026 at 1:02 PM UTC
- Author
- Kamo
- Commit
- cbc8efb
The signer-count check added last round demanded an EXACT match against the template's declared slots, which would have silently stopped mortgage disclosures going out. SecurityService's native-disclosure sender derives one signer per URLA borrower THAT HAS AN EMAIL, with no template awareness, so a template authored with borrower + co-borrower slots sent on a loan where only one borrower has an email supplies one signer for two slots — a normal, legitimate case. That path is wrapped in a try/catch that fails soft into NATIVE_SEND_FAILED, so an exact-match 400 would not surface as an error to anyone; it would present as "disclosures just aren't going out". Under-supply now proceeds and logs a WARN naming the template, both counts and the consequence: the unfilled slots' fields will not be signed. That is also today's behaviour, so allowing it is not a regression. Over-supply stays a 400. It is genuinely ambiguous — there is no correct slot to bind the extras to — and left alone it produces an envelope where every recipient is shown zero fields and can press Finish having signed nothing. The check stays where it was, above the first recipient save and the first invite email, so a rejected send still writes no row and mails nobody. The asymmetry is deliberate; requireSignerCountMatchesSlots is renamed requireSignerCountWithinSlots and its javadoc states both rules and why, so a future reader does not tidy it back to symmetric.