Tellier Benoit created JAMES-1820:
-------------------------------------
Summary: Data race condition in JMAP flags updates
Key: JAMES-1820
URL: https://issues.apache.org/jira/browse/JAMES-1820
Project: James Server
Issue Type: Bug
Components: JMAP
Affects Versions: master
Reporter: Tellier Benoit
Assignee: Antoine Duprat
If user A supply two concurent requests :
- one updating the **Seen** flag
- one updating the **Flagged** flag (marked as starred in thunderbird for
instance)
As a replace mode is used here, the two request will not commute and the
message will either be :
- Marked as unread but flagged
- Marked as read but unflagged
Depending of the execution order....
**Why do we care?**
Because one usually make several updates of single flags of the same message in
some very short time window (read + deleted // read + flagged // with longer
window : read + answered). So I expect this problem to be seen.
Because it is avoidable... **UpdateMessagePatch** is actually a week
reresentation that do not capture the fact that in JMAP these "flag" properties
are actually independent from one an other.
**How to solve this?** (In my opinion...)
I agree Mailbox API do not fit the requirements right know to solve this
problem, as Mailbox API do not provide other way to set and unset flags in a
single request (unless you do several calls). But this could be corrected by
making **FlagsUpdateCalculator** a higher level object, write for it a real
builder (that catches what kind of flags updates one truely want to do with
JMAP), and pass it by the **MessageManager** API.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
