When we send a message, the send recorder records the sent message.
When the client then appends an identical message to the sent folder,
the deduplication works and instead returns the message ID of the
existing proton message, rather than creating a new message. Gluon is
expected to notice that it already has this message ID and perform
some deduplication stuff internally.
However, it can happen that gluon doesn't yet have this message ID,
because we haven't yet received the "Message Created" event from the
API. To prevent this, we poll the events after send and wait for all
new events to be applied.
There's still a chance that the event wasn't generated yet on the API
side. Not sure what we can do about this.
Other: fixed case issue in SSL member function names.
Other: removed 'restart' mention in SMTP and IMAP SSL settings.
GODT-1846: modified gRPC server to introduce ConnectionMode settings.
GODT-1846: implemented connection mode handling in bridge-gui.
GODT-1846: implemented error reporting in bridge-gui for connection mode.
Other: gathered all IMAP/SMTP server settings.
GODT-1846: wired IMAP/SMTP port change errors.
Other: Renamed some error events and signals.
Other: Fixed crash in IMAP restart when not started.
Other: dismiss port error notifications before changing ports.
Other: misc. fixes.
Gluon used to have a bug where it would unnecessarily call the
reporter's ReportMessageWithContext method whenever an IMAP client would
drop unexpectedly. After fixing the bug, we can remove these gomock
EXPECT.AnyTimes() calls.
Bumping liteapi version made the test server stricter (more conformant
with the real server). As a result, one of the tests broke; fix should
be in GODT-1989, which is not ready yet.
Don't store the logrus entry as it might be possible that the standard
logrus logger can get changed in between resulting in stale pointers
inside the `Logrus.Entry` instance.
We now set disposition during attachment upload. However, this presents
a problem: some clients use inline disposition but don't provide a
content ID. Our API doesn't support this. To mitigate the issue, we just
fall back to attachment disposition in this case.
When manually installing an update, we want to manually install the
latest compatible version (`target`), not the absolute latest version
(`latest`). This is obviously a bug in the code because the mutex lock
being locked was `targetLock` but we were wrongly trying to install
`latest`.
