+
Skip to content

Conversation

link2xt
Copy link
Collaborator

@link2xt link2xt commented Oct 10, 2025

Closes #7290

@link2xt link2xt force-pushed the link2xt/non-call-in-reply-to branch from 5bbffb7 to 8339571 Compare October 10, 2025 21:18
… non-call Message-ID

In-Reply-To may refer to non-call message
as we do not control the sender.
It may also happen that call message
was received by older version and processed
as text, in which case correct In-Reply-To
appears to be referring to the text message.
@link2xt link2xt force-pushed the link2xt/non-call-in-reply-to branch from 8339571 to 87efbb7 Compare October 10, 2025 22:28
@link2xt link2xt marked this pull request as draft October 10, 2025 23:18
Any control information from the message
should only be downloaded when the message
is fully downloaded to avoid processing it twice.
Besides, "partial" messages may actually be full messages
with an error that are only processed as partial
to add a message bubble allowing to download the message later.
Ideally this receive_imf should not fail
to add replacement message,
but at least currently it tries to process
"call ended" messages due to a bug.
@link2xt link2xt force-pushed the link2xt/non-call-in-reply-to branch from 87efbb7 to a123432 Compare October 11, 2025 00:04
@link2xt link2xt marked this pull request as ready for review October 11, 2025 00:11
@link2xt
Copy link
Collaborator Author

link2xt commented Oct 11, 2025

First two commits have a test. Third does not because it is only to prevent IMAP loop from getting stuck in a loop if there is another unexpected bug.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IMAP loop stuck in infinite loop failing to receive_imf a message

1 participant

点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载