Skip to content

Commit 6783d70

Browse files
committed
exmdb: remodel exmdb_server::deliver_message's way of vivified mails
The deliver_message handler would only add message_id into the notify set if the DELIVERY_DO_RULES flag was given. However, when lda_twostep_processor is used, the DO_RULES flag for server-side rule processing is not set, since the client is supposed to take care of everything, new mail notification included. Now, in a twist, clients are not so much listening for events of type fnevNewMail, but rather fnevObjectCreated on content tables. When TWOSTEP was enabled, exmdb_server::deliver_message would not emit fnevObjectCreated, but lib/ruleproc.cpp would immediately call exmdb_server::notify_new_mail, which did emit fnevObjectCreated. In 9152bab, lib/ruleproc.cpp was changed from notify_new_mail to transport_new_mail, so deliver_message should have received a change to send fnevObjectCreated, but that did not happen. Fixes: gromox-2.46-89-g9152babd7 References: GXH-154, GXL-616, DESK-3712, DESK-3715, DESK-3716
1 parent 5a0315f commit 6783d70

File tree

2 files changed

+15
-2
lines changed

2 files changed

+15
-2
lines changed

doc/changelog.rst

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,12 @@
1+
Development 2.48.5
2+
==================
3+
4+
Fixes:
5+
6+
* fnevObjectCreate notifications were not sent when a mail was processed
7+
through TWOSTEP Rule Processor, now fixed
8+
9+
110
Gromox 2.48 (2025-07-31)
211
========================
312

exch/exmdb/message.cpp

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -70,6 +70,8 @@ struct DAM_NODE {
7070

7171
struct message_node {
7272
uint64_t folder_id = 0, message_id = 0;
73+
74+
auto operator<=>(const message_node &) const = default;
7375
};
7476

7577
struct rulexec_in {
@@ -3563,8 +3565,8 @@ static ec_error_t message_rule_new_message(const rulexec_in &rp, seen_list &seen
35633565
}
35643566
if (dam_list.size() > 0 && !message_make_dams(rp, std::move(dam_list), seen))
35653567
return ecError;
3566-
if (!b_del) try {
3567-
seen.msg.emplace_back(message_node{rp.folder_id, rp.message_id});
3568+
if (b_del) try {
3569+
std::erase(seen.msg, message_node{rp.folder_id, rp.message_id});
35683570
return ecSuccess;
35693571
} catch (const std::bad_alloc &) {
35703572
mlog(LV_ERR, "E-2029: ENOMEM");
@@ -3777,6 +3779,8 @@ BOOL exmdb_server::deliver_message(const char *dir, const char *from_address,
37773779
mlog(LV_DEBUG, "to=%s from=%s fid=%llu delivery mid=%llu (%s)", account.c_str(),
37783780
znul(from_address), LLU{fid_val}, LLU{message_id},
37793781
partial ? " (partial only)" : "");
3782+
3783+
seen.msg.emplace_back(fid_val, message_id);
37803784
if (dlflags & DELIVERY_DO_RULES) {
37813785
auto ec = message_rule_new_message({from_address, account.c_str(), cpid, b_oof,
37823786
pdb->psqlite, fid_val, message_id, std::move(digest)}, seen);

0 commit comments

Comments
 (0)