POST with `threadOf` hangs indefinitely when email plugin is not configured

[emmanuel-sarpedon]

Bug description

When posting a comment with a threadOf field via the REST API, Strapi never sends a response. The request hangs until the client times out. Removing threadOf from the payload makes the request succeed immediately.

Steps to reproduce

1. Install strapi-plugin-comments v3.2.4 on Strapi v5
2. Do not configure any email provider (or leave the default one unconfigured)
3. Create a root-level comment (no threadOf) — this works fine
4. Send a POST to create a reply to that comment:

POST /api/comments/api::page.page:<documentId>
Content-Type: application/json
 
{
  "author": {
    "id": "user1",
    "name": "John",
    "email": "john@example.com"
  },
  "content": "This is a reply",
  "threadOf": 35
}

5. The request hangs indefinitely — no response, no HTTP error

Expected behavior

The comment should be created and a 200 response returned. If the email notification fails, it should be caught gracefully and the comment creation should still succeed.

Root cause

After creating a threaded comment, the client service calls sendResponseNotification(), which attempts to send an email to the parent comment's author via strapi.plugin("email").service("email").send(...).

When no email provider is configured, this call either hangs forever (SMTP connection timeout) or throws an unhandled error that prevents the HTTP response from being sent.

The relevant code path in dist/server/index.js:

// Inside create():
try {
  await this.sendResponseNotification(result)
} catch (e) {
  console.error(e)
}
 
// Inside sendResponseNotification():
await strapi.plugin("email").service("email").send({...})

The try/catch in create() should handle this, but in practice the request still hangs — suggesting the email send() call never resolves or rejects.

Workaround

Override sendResponseNotification via plugin extension to disable it entirely:

// src/extensions/comments/strapi-server.ts
 
export default (plugin) => {
  const originalClientFactory = plugin.services.client;
 
  plugin.services.client = (context) => {
    const service = originalClientFactory(context);
 
    // Disable email notification on comment replies.
    // The plugin calls this after creating a threaded comment,
    // which hangs if the email provider is not configured.
    service.sendResponseNotification = async () => {};
 
    return service;
  };
 
  return plugin;
};

This works but is fragile — it depends on the internal service structure and will break if the service API changes.

Suggested fix

A few possible approaches that would be more stable:

• Guard the notification call: check that the email plugin is available and properly configured before attempting to send. Something like:

  if (strapi.plugin("email")?.service("email")) {
    try {
      await this.sendResponseNotification(comment);
    } catch (e) {
      strapi.log.warn("[Comments] Failed to send reply notification:", e.message);
    }
  }

• Add a config option (e.g. enableReplyNotification: boolean) to let users opt out of the notification feature explicitly
• Add a timeout on the email send() call so it doesn't hang forever even if SMTP is misconfigured

Environment

Environment

• Plugin version: 3.2.4
• Strapi version: 5.42
• Node.js: 24
• Database: PostgreSQL
• Email plugin: Not configured (default)