[
https://issues.apache.org/jira/browse/JAMES-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813200#comment-17813200
]
Zhivko Vasilev commented on JAMES-3979:
---------------------------------------
This doesn't look right to me.
This violates what RFC says
https://datatracker.ietf.org/doc/html/rfc8620
state: "String"
If the data changes, this string MUST change. If the Foo data is unchanged,
servers SHOULD return the same state string on subsequent requests for this
data type.
I've added a retry mechanism, but even with 20 iterations of 250 milliseconds
each, it sometimes fails. This makes integration tests very unstable.
I have not taken a look at how JAMES implements this. However, several years
ago, I had to implement similar logic with Cassandra. One additional table with
TTL.
timed-uuid/mailbox-uuid/folder-uuid/msg-uuid or
mailbox-uuid/timed-uuid/folder-uuid/msg-uuid
I do not remember the details, but it was something like that, where
mailbox-uuid/timed-uuid had the role of the state.
Each mutation just added an entry in that table with a lightweight transaction.
But it is up to you , I'll stick with what works :)
> "Email/import" doesn't change the state
> ---------------------------------------
>
> Key: JAMES-3979
> URL: https://issues.apache.org/jira/browse/JAMES-3979
> Project: James Server
> Issue Type: Bug
> Components: JMAP
> Reporter: Zhivko Vasilev
> Assignee: Antoine Duprat
> Priority: Minor
> Attachments: james_email_import_response.json
>
>
> I have created an automated test in which two app instances run on one
> account. In this test, app1 imports emails into different folders or changes
> email properties (read/unread/etc.), and the other app syncs and checks that
> they are okay.
> However, it seems that "Email/import" doesn't change the state. As a result,
> the sync from the other app instance cannot detect the changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
