[jira] [Created] (JAMES-3557) Fail with cannotCalculateChanges when a single change exceed maxChanges

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

Benoit Tellier created JAMES-3557:
-------------------------------------

             Summary: 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


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