bug report: Email message ID = thread ID for threads with more than 1 email

Summary

The Feishu Mail API appears to return thread_id == message_id for some emails that belong to multi-message inbox threads.

For single-message threads, this may be expected. For multi-message threads, this makes thread_id unreliable as a stable conversation key.

Expected behavior

Messages that belong to the same conversation should share a stable thread_id.

Actual behavior

For some inbox emails that are part of a multi-message thread, the API returns thread_id equal to the current message_id instead of a thread identifier shared across the conversation.

Reproduction steps

1. Export mailbox metadata for a date range and group records by thread_id.
2. Identify a case where the grouped thread contains more than one email and at least one email in that thread has message_id == thread_id.
3. Fetch that same message again from the live Mail API.
4. Observe that the live API still returns message_id == thread_id.

Example observation

A multi-email inbox thread was grouped with email_count: 2, and one message in that thread had:

{
  "message_id": "<redacted-message-id>",
  "thread_id": "<redacted-message-id>",
  "subject": "<redacted-subject>"
}

The same message fetched again from the live Mail API returned:

{
  "message_id": "<redacted-message-id>",
  "thread_id": "<redacted-message-id>",
  "subject": "<redacted-subject>",
  "references": "",
  "smtp_message_id": "<redacted-smtp-message-id>",
  "in_reply_to": null
}

Commands used

Export mailbox data

& '<redacted-script-path>\Get-LarkMailRange.ps1' `
  -StartDate '2026-04-13' `
  -EndDate '2026-04-19' `
  -Folders inbox,sent `
  -PageSize 100 `
  -BatchSize 10 `
  -RequestTimeoutMs 120000 `
  -EnrichFormat metadata `
  -MetadataProfile rich `
  -OutputPath '<redacted-output-path>'

Fetch a live message from the Mail API through lark-cli

@'
const { spawnSync } = require("child_process");
const runJs = process.env.APPDATA + "\\npm\\node_modules\\@larksuite\\cli\\scripts\\run.js";
const r = spawnSync("node", [
  runJs,
  "mail","user_mailbox.messages","get",
  "--as","user",
  "--format","json",
  "--params", JSON.stringify({
    user_mailbox_id: "me",
    message_id: "<redacted-message-id>",
    format: "metadata"
  })
], { encoding: "utf8", windowsHide: true, timeout: 120000 });
console.log(r.stdout);
'@ | node -

Impact

Any integration that relies on thread_id to group emails into conversations may mis-group some messages or may not be able to trust thread_id as a stable thread key.

Request

Please confirm whether this behavior is expected.

If not, please investigate why thread_id can equal the current message_id for emails that are part of a multi-message inbox thread.

The section names are normal Markdown headings for a GitHub issue. This is already one complete Markdown document, not separate pieces.

Start with the mailbox export and live lark-cli Mail API reproduction commands in the issue, comparing message_id, thread_id, references, smtp_message_id, and in_reply_to for a multi-message conversation. Done means determining whether the API response is expected and, if it is a CLI defect, identifying the affected Mail message handling and documenting the verified behavior.