fix: Send pre-message after successful sending of post-message (#8063)#8222
fix: Send pre-message after successful sending of post-message (#8063)#8222iequidoo wants to merge 2 commits into
Conversation
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
2 times, most recently
from
04832ec to
fed3a6a
Compare
| } | ||
|
|
||
| async fn handle_post_message( | ||
| async fn update_from_post_msg( |
There was a problem hiding this comment.
Decided to rename it to underline that only an already existing message is updated, to avoid more bugs caused by not fully handling post-messages
There was a problem hiding this comment.
What bug was caused by this?
There was a problem hiding this comment.
See #8222 (comment), probably the wrong condition was added there because handle_post_message() looks like hadndling post-messages in all cases. Actually it only updates existing messages
|
|
||
| // Maybe set logging xdc and add gossip topics for webxdcs. | ||
| for (part, msg_id) in mime_parser.parts.iter().zip(&created_db_entries) { | ||
| if mime_parser.pre_message != PreMessageMode::Post |
There was a problem hiding this comment.
Compat problem: missing iroh topic id
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
from
fed3a6a to
42d09d4
Compare
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
from
42d09d4 to
f6eacd1
Compare
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
from
f6eacd1 to
2947c49
Compare
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
from
2947c49 to
29a6f8d
Compare
| "Message {rfc724_mid} is already in some chat or deleted." | ||
| ); | ||
| if mime_parser.incoming { | ||
| return Ok(None); |
There was a problem hiding this comment.
I'm having problems understanding why the changes here are necessary, can you clarify?
There was a problem hiding this comment.
If a post-message appears on IMAP, it should be deleted from smtp because it was sent successfully. Now this logic is common for all outgoing messages. One test started failing before i made this change, but i've forgotten which one exactly.
| } | ||
|
|
||
| async fn handle_post_message( | ||
| async fn update_from_post_msg( |
There was a problem hiding this comment.
What bug was caused by this?
|
I see the main problem with this PR is adding the
Need to take some decision here. For now have chosen the last one. |
Messages are deleted from the inbox loop, so it should be interrupted. The SMTP doesn't need to be interrupted explicitly however, chat::sync() already does this internally.
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
from
29a6f8d to
e6de2a6
Compare
Also, send the message text in the post-message too, we can't support the workaround for duplicated message text shown in ancient versions anymore, otherwise newer versions won't show the message text at all. On the receiving side, don't download a post-message w/o known pre-message if the post-message exceeds DownloadLimit to save user's traffic. This isn't easy to test in Rust though because the `smtp` sending code requires an SMTP connection, so it's only tested (by already existing tests) that messages are queued in the right order. Another problem is that the `smtp` sending logic doesn't try to send any messages following a failed-to-send message until the retry limit is reached, so if there's smth wrong with a post-message, other unrelated messages are delayed, but this problem has already existed.
iequidoo
force-pushed
the
iequidoo/send-post-msg-first
branch
from
e6de2a6 to
773f6fb
Compare
| .await?; | ||
| } | ||
|
|
||
| sql.execute("DELETE FROM available_post_msgs", ()).await?; |
There was a problem hiding this comment.
Usually we don't do so, but decided to clean up the table in case of an "upgrade again" scenario. Don't want to add a migration and migrations are executed only once. Can be removed once we add a migration deleting the table.
2 participants
Also, send the message text in the post-message too, we can't support the workaround for duplicated
message text shown in ancient versions anymore, otherwise newer versions won't show the message text
at all.
On the receiving side, don't download a post-message w/o known pre-message if the post-message
exceeds DownloadLimit to save user's traffic.
This isn't easy to test in Rust though because the
smtpsending code requires an SMTP connection,so it's only tested (by already existing tests) that messages are queued in the right order.
Another problem is that the
smtpsending logic doesn't try to send any messages following afailed-to-send message until the retry limit is reached, so if there's smth wrong with a
post-message, other unrelated messages are delayed, but this problem has already existed.
Fix #8063