Friend-request email notifications
- Send a friend request using an existing member’s exact login ID or email. Previously requests were in-app only; the service now attempts a notification to the verified recipient after saving the request. The email links to Friends, where the recipient signs in and accepts or declines. Emails never accept requests automatically or reveal either member’s email to the other. Check Spam as well as Inbox.
- Only eligible active verified existing accounts are notified. Unknown addresses are not invited; blocked, canceled, accepted or unavailable requests are skipped before sending. Repeating a pending request can queue a missing notification from before this update, but a successfully sent notification is not resent. Existing requests are not bulk-emailed by deployment.
- Anti-spam limits allow at most one queued notification per sender/recipient pair per day and ten new notifications per recipient per day. Up to five delivery attempts occur within 24 hours, using backoff and a stable provider idempotency key. The scheduled worker retries up to three due emails per pass; the existing roughly 15-minute host schedule can delay retries. Requests remain visible in Friends even if notification delivery fails.
- Administrators can pause Friend-request emails under Features without disabling in-app requests or verification/recovery mail. Run Friend request notification queue in Feature tests for retained status counts. Sent means accepted by the email provider, not proof of inbox delivery. Private queue metadata is retained up to 30 days while the worker is enabled; it stores account IDs/status, not email bodies or addresses.
Open feature · All guides