CI is failing, because python tests need to be adapted to this change.

In case anyone else is wondering: GitHub doesn't show that this is part of the "2.x keycontact releases" in the right pane of this PR, because chatmail/core is not in the deltachat organization.

CI is failing, because python tests need to be adapted to this change.

hum, i assume, that there similar adaptions wrt get_msg_cnt() are needed. i am not deep into python, and i do not have a setup where python tests run locally, so it'd be great if someone else can adapt them

Summary of my review: Some small things, and the problem that this does lead to double "e2ee info messages" on secure join. I can see to repair the tests, but the bigger problem right now are these double messages.

Not sure what the best solution is. Querying whether the previous message is an e2ee info message, and if so, removing it, comes to mind. Generally, we could just modify get_chat_msgs_ex() to statically add an e2ee info message to the top (it already adds daymarkers, so it can also add some info message). But then get_chat_msgs_ex() would have to query for whether there is any protection-enabled message, and if not, add the e2ee info message, not sure about the performance impact of this.

yip, the double "messages are end-to-end-encrypted" is bad.

however, the old secure-join-messages also seem outdated - imu, the chat, if is_encrypted() is true, is e2ee from the very beginning on, it makes sense to say that already then, as whatsapp and other are doing - but then we have the flow:

1. "Messages are end to end-encrypted. Tap to learn more."
2. "Establishing end-to-end-encryption..."
3. "Messages are end to end-encrypted. Tap to learn more."

imu, 2. and 3. are no longer related to e2ee-yes-or-not - but are used for getting the keys and/or protecting it against mitm

if so, maybe reword 2. and 3. that would fix the issue.

having these messages as markers seem to be some more effort and maybe sth. for the future.

EDIT: we found another way to tweak, see below

talked with @hpk42 , a simple fix covering all interesting paths might be to check for can_send() before adding e2ee-info-message

talked with @hpk42 , a simple fix covering all interesting paths might be to check for can_send() before adding e2ee-info-message

this is fine for Bob (the scanner), but Alice (the inviter showing the qr code) still gets two e2ee-info-messages as at the time the chat is created it is probably sendable. as all other cases seem to be fine, i will have a closer look at that case ...

@Hocuri thanks a lot for the review, i applied most suggestions - and added an can_send / blocked condition before adding the e2ee-info-message

for the python-tests, would be great if you can have a look there

btw, the PR is running nicely on my iOS phones already

Macos tests are super flaky :/ now they failed with:

2025-07-18T18:49:42.8473920Z >       log.section("ac1 clone detects that message is marked as seen")
2025-07-18T18:49:42.8474140Z 
2025-07-18T18:49:42.8474200Z tests/test_multidevice.py:88: 
2025-07-18T18:49:42.8474430Z _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
2025-07-18T18:49:42.8474580Z 
2025-07-18T18:49:42.8475050Z self = <deltachat_rpc_client.pytestplugin.log.<locals>.Printer object at 0x000000011091a0c8>
2025-07-18T18:49:42.8475380Z msg = 'ac1 clone detects that message is marked as seen'
2025-07-18T18:49:42.8475530Z 
2025-07-18T18:49:42.8475920Z     def section(self, msg: str) -> None:
2025-07-18T18:49:42.8476120Z         print()
2025-07-18T18:49:42.8476250Z >       print("=" * 10, msg, "=" * 10)
2025-07-18T18:49:42.8476440Z E       OSError: [Errno 9] Bad file descriptor

Will rerun them, but I have no idea what to systematically do about this.

Btw, I just tried to ask Copilot about this error, just for the fun of it, and thinking maybe it has some helpful suggestion. Well, it did not, but wrote a long text about why this problem was caused by a DNS resolution problem. I doubt it 😂

thanks a lot ❤️