Quote Email Fails with a Provider Configuration Error

Decision: make ERR_1600 name a boundary

Artifact truth

The exact quote revision produced a non-empty PDF with a known MIME type, byte count, and digest, or it did not.

Message truth

The application selected a valid recipient, a verified sender, a rendered template, and the intended PDF under one logical send reference, or it did not.

Delivery truth

The provider was never called, rejected the handoff, accepted it, reached the recipient server, later failed, or became visible. These are different states.

Eight boundaries to prove in order

1. Logical send. Allocate one opaque request reference for one quote revision and one intended recipient. Reuse it only for reconciliation and safe retries.
2. Quote snapshot. Freeze or version the business data used to generate the document so a retry cannot silently send a different quote.
3. PDF artifact. Prove generation completed, bytes are non-empty, the type is application/pdf, and the artifact digest matches the attachment.
4. Message composition. Validate the recipient privately, resolve a verified sender, render subject and body, and attach the expected artifact before provider code runs.
5. Encoded size. Measure the full MIME message after transfer encoding, not only the raw PDF. Headers, boundaries, and base64 expansion consume the provider limit.
6. Provider readiness and handoff. Separate missing config, bad credentials, wrong region or endpoint, TLS failure, connectivity failure, and unverified sender identity.
7. Provider and SMTP outcome. Persist a stable message ID and authenticated delivery events. API or relay acceptance is not final delivery.
8. Recipient and business outcome. Keep recipient-server acceptance, inbox visibility, and the application's quote status separate.

Turn one generic error into a bounded contract

{
  "requestRef": "opaque-log-safe-id",
  "stage": "artifact | compose | provider_connect | provider_submit | delivery",
  "class": "pdf_failed | invalid_recipient | sender_unverified |
            message_too_large | provider_auth | tls | network |
            provider_rejected | delivery_failed",
  "retryable": false
}

Return a generic customer-facing message where privacy requires it, but keep the exact bounded stage and class in protected operations data. The request reference should connect the UI response, quote revision, job, provider message ID, and delivery event without copying a recipient address or quote content into routine logs.

Measure the encoded attachment

MIME base64 transfer encoding expands binary content by roughly four encoded characters for every three input bytes, before line breaks, headers, and multipart boundaries. A PDF that appears below the provider's raw attachment limit may still make the final message too large. Build and measure the complete message, then keep operating margin rather than targeting the exact ceiling.

If the document cannot fit, prefer an authenticated, expiring retrieval flow tied to the quote and recipient authorization. A public object URL, analytics event, or support comment must not expose a quote document.

Retry the logical send, not the business action

1. Persist one logical send keyed to quote revision, intended recipient identity, and message purpose.
2. Store each provider attempt beneath it with the provider message ID and a monotonic state.
3. Retry temporary network, 4xx SMTP, or provider-delay outcomes with bounded backoff and the same logical identity.
4. Require corrected state before retrying invalid recipients, bad credentials, unverified senders, or oversized messages.
5. Make authenticated webhook processing idempotent so duplicate or out-of-order events cannot create duplicate activity records or regress final evidence.

What the public report proves

worksquares/cpq-issues issue 12 reports a fresh web failure where sending a generated quote to a customer returns ERR_1600 and a generic provider-configuration message. The report explicitly lists missing configuration, credentials, sender address, connectivity, recipient data, PDF generation, attachment size, and template rendering as unresolved possibilities.

The published response contains an application error and request ID, but no provider response, SMTP stage, PDF artifact evidence, or delivery event. It therefore does not yet prove that the provider configuration is the failing boundary. The first useful change is better stage evidence, followed by one controlled send after the PDF and message are proven.

Acceptance tests before release

1. Make PDF generation fail and prove that the provider call count stays zero and the error stage is artifact.
2. Remove the recipient or use an unverified sender and prove that the provider is not called and no quote activity is marked sent.
3. Use a fixture just below the raw PDF limit but above the encoded-message limit and prove that composition rejects it before submission.
4. Force authentication, TLS, connectivity, and provider rejection separately and verify that each produces a distinct protected error class without printing credentials.
5. Return provider acceptance, then deliver a delayed or bounced event and prove that the quote state advances monotonically without duplicate sends.
6. Retry the same logical send after a temporary failure and prove that one quote activity and one final recipient outcome remain.