[jira] [Created] (JAMES-1820) Data race condition in JMAP flags updates

["Tellier Benoit (JIRA)" <se...@james.apache.org>]

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org