Skip to content

fix: Make pre-messages w/o text want MDNs (#8004)#8008

Open
iequidoo wants to merge 3 commits intomainfrom
iequidoo/test_markseen_pre_msg
Open

fix: Make pre-messages w/o text want MDNs (#8004)#8008
iequidoo wants to merge 3 commits intomainfrom
iequidoo/test_markseen_pre_msg

Conversation

@iequidoo
Copy link
Collaborator

@iequidoo iequidoo commented Mar 18, 2026

This fixes failing test_pre_msg_mdn_before_sending_full. Maybe it's even good that MDNs will
be sent for pre-messages only having placeholder text with the viewtype and size, at least this way
we notify the contact that we've noticed the message. Anyway, with adding message previews the
problem will be solved for the corresponding viewtypes.

Fix #8004

@iequidoo iequidoo force-pushed the iequidoo/test_markseen_pre_msg branch from 4fdd476 to 9afce7d Compare March 18, 2026 14:01
@iequidoo iequidoo requested review from Hocuri and link2xt March 18, 2026 14:06
@iequidoo
Copy link
Collaborator Author

I made a bug in the test -- bob doesn't accept the chat -- and this looks suspicious to me:

alice WARN: src/mimeparser.rs:435: decryption failed: decrypt_with_keys: missing key
alice INFO: src/receive_imf.rs:520: Receiving message "ffc78f9e-5ca0-4ab0-8379-8b9150fedfac@localhost", seen=false...
alice INFO: src/contact.rs:1094: Added contact id=1002 addr=bob@example.net.
alice INFO: src/receive_imf.rs:1442: Non-group message, no parent. num_recipients=1. from_id=Contact#1002. Chat assignment = OneOneChat.
alice INFO: src/receive_imf.rs:1771: No chat id for message (TRASH).
alice INFO: src/receive_imf.rs:2356: Message has 1 parts and is assigned to chat #Chat#Trash.
test tests::pre_messages::receiving::test_pre_msg_mdn ... FAILED

Why is bob's self-MDN being processed after the decryption failure? It should go to the trash just because of that and no message should be tried to be added.

@iequidoo iequidoo force-pushed the iequidoo/test_markseen_pre_msg branch from 9afce7d to d3370d5 Compare March 18, 2026 15:14

pub async fn pop_sent_msg_opt(&self, timeout: Duration) -> Option<SentMessage<'_>> {
let from_head = self
.get_config_bool(Config::PopSentMsgFromHead)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we instead have a new function shift_sent_msg_opt that does this and not a global config that is only used for tests? Otherwise we will have to add this config to all tests over time.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Otherwise we will have to add this config to all tests over time.

Why? Only to those where sending messages from head is needed to reproduce some regression. Anyway, do you mean adding a function that moves an smtp job from head to tail?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I mean creating a function shift_sent_msg_opt that takes message from the beginning of the queue rather than the end, so we can use it in new tests.

Copy link
Collaborator Author

@iequidoo iequidoo Mar 20, 2026

Choose a reason for hiding this comment

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

The first i wanted to do is to create unqueue_sent_msg_opt() which does the same as pop_sent_msg_opt(), but takes the first queued message. But there are other functions calling pop_sent_msg_opt(), so we should forward some flag everywhere. E.g. in the new test it's send_msg() returning SentMessage. Note sure you mean the same, what does shift_ mean? Anyway, i'd avoid adding a flag everywhere, better we add a new Config key or some flag (maybe one-shot) to Context.

I also don't expect many tests needing this, so a config key doesn't look like a problem.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Also it appeared that not the sending order is a problem, but absence of message text, so i can drop this part at all. But as it's already done, maybe let it remain?

…essage (#8004)

Actually, the problem in #8004 is that a pre-message doesn't "want MDN" if it has no text. Anyway,
the added test reproduces the bug.
@iequidoo iequidoo force-pushed the iequidoo/test_markseen_pre_msg branch from d3370d5 to d2f33f5 Compare March 20, 2026 16:01
@iequidoo iequidoo changed the title test: MDN on pre-message has effect if received before sending full message (#8004) fix: Make pre-messages w/o text want MDNs (#8004) Mar 21, 2026
@iequidoo iequidoo requested review from link2xt and r10s March 21, 2026 12:37
This fixes the failing `test_pre_msg_mdn_before_sending_full`. Maybe it's even good that MDNs will
be sent for pre-messages only having placeholder text with the viewtype and size, at least this way
we notify the contact that we've noticed the message. Anyway, with adding message previews the
problem will be solved for the corresponding viewtypes.
@iequidoo iequidoo force-pushed the iequidoo/test_markseen_pre_msg branch from 9a4b1ed to 40058de Compare March 21, 2026 12:41
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.

read-receipts not always displayed

2 participants