Date Sort Order compromized

Issues
1

Issue Description

I got a report that suddenly old mail shows up on the inbox. The same I can confirm on GMail on mobile and Thunderbird on computer for my own mail. In Thunderbird I can sort and it resorts properly, but that is a manual override. And it does not change display in Gmail App. So it seems the database index is sorting correctly. Happened after we moved a large mail account but obviously not just on that large mail account.
Log is on trace, but does not show anything in the UI
I have not even an idea how to debug this, any help much appreciated!

Expected Behavior

Display eMail in descending date order by default.

Actual Behavior

Inbox corrupted, showing two newer mails then mails from 2025.
In Thunderbird mails still show, in GMail mails between last mail and 2025 went amiss.

Reproduction Steps

Open Mail Client.
Where can I recreate the mail index?
What logs would be relevant. I cannot see any. But as that happens on multiple mail clients, the cause is very likely on the server side?

Relevant Log Output

Don’t know what is “relevant”?
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Write batch operation
Jun 03 01:43:29 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP connection started
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP input received
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache miss
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache miss
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Authentication successful
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache miss
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP input received
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP ID command
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP input received
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP SELECT command
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP LIST command
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP input received
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP SEARCH command
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP input received
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP ID command
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP input received
Jun 03 01:43:48 mindship-syl stalwart[2614]: Data store iteration operation
Jun 03 01:43:48 mindship-syl stalwart[2614]: Cache hit
Jun 03 01:43:48 mindship-syl stalwart[2614]: IMAP SEARCH command
Jun 03 01:43:48 mindship-syl stalwart[2614]: Raw IMAP output sent

Stalwart Version

v0.16.x

Installation Method

Built from source

Database Backend

PostgreSQL

Blob Storage

Filesystem

Search Engine

Internal

Directory Backend

Internal

Additional Context

Gmail Version 2026.05.11
Thunderbird 140.11
Stalwart 0.16.5
stalwart-cli 1.0.6

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

The key information is in the AccountMaintenance task description. The issue is very likely related to IMAP UIDs being out of order after the large mail account was moved – which is exactly why Stalwart has a “recalculate IMAP UIDs” maintenance operation.

Here’s what’s happening and what you can do:

The root cause is almost certainly that after migrating the large mail account, messages were ingested with UIDs (or internal sequence positions) that don’t reflect their actual dates. IMAP clients display messages in UID/sequence order by default – so if older messages got higher UIDs than newer ones (which can happen during a bulk import/migration), clients without client-side re-sorting (like Gmail mobile) will show them out of chronological order.

What to try:

Run an AccountMaintenance task with the “recalculate IMAP UIDs” operation for the affected account(s). This can be triggered via the WebUI (Management > Tasks > Scheduled), the CLI (stalwart-cli create task/AccountMaintenance), or the JMAP API. According to the docs:

The AccountMaintenance variant runs a per-account maintenance operation… recalculating IMAP UIDs, or recalculating storage quota usage.

This recalculation should reorder the UIDs to reflect a consistent state. However, be aware that changing UIDs is a disruptive event for IMAP clients – they will need to re-sync the affected mailboxes afterward (this is normal and expected).

You may also want to run this for all affected accounts, not just the one that was migrated, since you note the issue appeared on other accounts too.

For more detail on triggering tasks, see the Tasks documentation.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

This probably is happening because the index process has not finished yet. Also check your logs for any errors with the index.