Skip to content

fix(db): Hash long IMAP message IDs #10178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

ChristophWurst
Copy link
Member

Fixes #6618.

@@ -235,7 +235,7 @@ public function writeThreadIds(array $messages): void {
foreach ($messages as $message) {
$query->setParameter(
'thread_root_id',
$message->getThreadRootId(),
mb_substr($message->getThreadRootId(), 0, 1023),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How often will the prefix of thread_root_id be the same causing collisions? Would hashing to 1k bytes provide better resiliency against collisions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hard to say. Hashing long values could be a good idea for long messages. I'll look into that!

@ChristophWurst ChristophWurst changed the title fix(db): Truncate long IMAP message IDs fix(db): Hash long IMAP message IDs Mar 11, 2025
@ChristophWurst ChristophWurst marked this pull request as draft March 11, 2025 07:58
@ChristophWurst
Copy link
Member Author

I'm getting unsure about the approach, regardless of going with truncation or hashing. The INSERTs and UPDATEs will be fine. But threading might fall apart when we use the header information later to build threads. E.g. in references we don't normalize message ids, but in the other fields we do. Mixing all of them will lead to partial threads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'in_reply_to' at row 1
2 participants