[Bug]: Single send produces duplicate copies in Sent folder when on flaky connection (iOS PWA)

[tstreule]

Description

When sending a reply over an unstable network connection, a single click on "Send" resulted in the same email being saved 6 times in the Sent folder. It's unclear whether the message was also delivered to the recipient multiple times. This appears to be a retry / idempotency issue when the network is degraded.

Steps to Reproduce

Not reliably reproducible, but the conditions were:

1. Install webmail as a PWA on iOS (Safari → webmail.example.com → "Add to Home Screen").
2. Open the PWA on a poor/intermittent network connection (traveling abroad, weak signal).
3. Open an existing email and click "Reply".
4. Compose a reply and click "Send" once.
5. Open the Sent folder.

Expected Behavior

A single click on "Send" should result in exactly one message in the Sent folder, regardless of network quality. If the request times out or fails, the client should either retry idempotently (without creating duplicates) or surface an error to the user rather than silently re-sending.

Actual Behavior

The reply appeared 6 times in the Sent folder despite "Send" being clicked only once. No error or duplicate-send warning was shown in the UI.

Bulwark Version

1.7.1

Stalwart Mail Server Version

0.16.6

Browser

Safari

Operating System

iOS

Screenshots / Screen Recording

No response

Relevant Logs or Error Output

Additional Context

No response

[franko-c]

looks like two layers compound here. email-composer.tsx:1230 handleSend() has no re-entry guard, so the button stays clickable while the first send is in-flight. each tap queues a new sendEmail() call against the JMAP client.

the transport layer then doubles each attempt. client.ts:434 retries once after 1s on network errors (lines 448-450), and each call generates a fresh creation ID (send-${Date.now()} at line 2099). 3 taps × 2 attempts = 6 copies.

const sendingRef = useRef(false);

const handleSend = async (skipAttachmentCheck = false) => {
  if (sendingRef.current) return;
  sendingRef.current = true;
  try {
    // ... existing send logic
  } finally {
    sendingRef.current = false;
  }
};

haven't looked at whether the iOS service worker adds its own retry on top