[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] [Closed] (JAMES-3557) Fail with cannotCalculateChanges when a single change exceed maxChanges
From:       "Benoit Tellier (Jira)" <server-dev () james ! apache ! org>
Date:       2021-04-27 3:03:00
Message-ID: JIRA.13370531.1617939791000.346072.1619492580574 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/JAMES-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Benoit Tellier closed JAMES-3557.
---------------------------------
    Fix Version/s: 3.6.1
                   3.7.0
       Resolution: Fixed

> Fail with cannotCalculateChanges when a single change exceed maxChanges
> -----------------------------------------------------------------------
> 
> Key: JAMES-3557
> URL: https://issues.apache.org/jira/browse/JAMES-3557
> Project: James Server
> Issue Type: Sub-task
> Components: JMAP
> Affects Versions: 3.6.0
> Reporter: Benoit Tellier
> Assignee: Antoine Duprat
> Priority: Major
> Fix For: 3.7.0, 3.6.1
> 
> Time Spent: 1h 50m
> Remaining Estimate: 0h
> 
> h3. Symptoms
> https://github.com/iNPUTmice/jmap/issues/47#issuecomment-816353104 tests by Daniel \
> Gultsch on the LTTRS led to James stucking itself in the email changelog, failing \
> to resynchronise itself: {code:java}
> [
> "Email/changes",
> {
> "accountId": "cf2e474f942d8ea3192028d2e37d5b08b3ddd36fb986d2ad6a19d66277a981c4",
> "oldState": "4887d9c1-9707-11eb-b57c-1b93c9e59cb7",
> "newState": "4887d9c1-9707-11eb-b57c-1b93c9e59cb7",
> "hasMoreChanges": true,
> "created": [],
> "updated": [],
> "destroyed": []
> },
> "3"
> ]
> {code}
> This is an issue, as a client will not be able to receive changes past that one, \
> essentially breaking the synchronisation logic. h3. Explanation
> I did easily succeeded to reproduce that behaviour by having the number of items in \
> a single state change exceeding the limit: {code:java}
> @Test
> default void test() {
> EmailChangeRepository repository = emailChangeRepository();
> MessageId messageId = generateNewMessageId();
> State state = generateNewState();
> EmailChange oldState = EmailChange.builder()
> .accountId(ACCOUNT_ID)
> .state(state)
> .date(DATE.minusHours(1))
> .isDelegated(false)
> .created(messageId)
> .build();
> final State newState = generateNewState();
> EmailChange change = EmailChange.builder()
> .accountId(ACCOUNT_ID)
> .state(newState)
> .date(DATE)
> .isDelegated(false)
> .updated(messageId, generateNewMessageId(), generateNewMessageId(), \
>                 generateNewMessageId(), generateNewMessageId(), \
>                 generateNewMessageId())
> .build();
> repository.save(oldState).block();
> repository.save(change).block();
> System.out.println(repository.getSinceState(ACCOUNT_ID, oldState.getState(), \
> Optional.empty()).block()); }
> {code}
> lead to:
> {code:java}
> EmailChanges{newState=State{value=ce31b717-edff-4a27-bb28-5482a541c1e0}, \
> hasMoreChanges=true, created=[], updated=[], destroyed=[]} {code}
> Translation: the default maximum number of changes (5...) is exceeded by a single \
> entry of the changelog. h3. The fix?
> What to do from here:
> - Specify the maxChanges property to override the (stupid) James default
> - We should increase this default to IMO at leat 256, we should rely on injections \
>                 to have a (convenient) lower value in our tests
> - We should  avoid stucking our selves like that... => we should return \
> canNotCalculateChanges to let it explicitly know to the client.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]