You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2021/04/27 03:03:00 UTC
[jira] [Closed] (JAMES-3557) Fail with cannotCalculateChanges when
a single change exceed maxChanges
[ 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