ottoka commented on PR #1111: URL: https://github.com/apache/james-project/pull/1111#issuecomment-1210779409
This is interesting. In the latest version, InMemoryMessageMapper does lookup up an existing message by mailbox+UID and updates it if it exists. This breaks MemoryMessageIdMapperTest>MessageIdMapperTest.findMailboxesShouldReturnTwoMailboxesWhenMessageExistsInTwoMailboxes(). Turns out that when the test saves its original four messages, it puts message4 into mailbox 2. During this the message4 gets UID 1 from the AbstractMessageMappers built-in InMemoryUidProvider, since the latter knows about mailboxes and it was empty before, so UID 1 is fine. But then the test creates and saves copy of message1, and gives it a UID via the MessageUidProvider from the tests own InMemoryMapperProvider. MessageUidProvider is a different implementation that does not now about mailboxes but provides UIDs based on a simple counter. So message1copy **also** gets UID 1 by accident. When trying to save it in mailbox 2, it already finds message4 with UID 1 there due to the UID conflict, and updates it instead, which breaks the test. In contrast, the original implementation just **overwrites** message4 with message1copy in this case, which seems like a bug to me! Now I wonder if this kind of UID generator conflict can happen in production as well? I had thought a UID would be **u**nique wherever it came from. Or is it again an artifact of the simplified InMemoryXXX implementations? In the first case we should dig into the issue some more. In the second case, I believe the test should be adjusted to prevent the conflict, i.e. just fast-forwarding the tests MessageUidProvider to a non-conflicting UID. Any suggestions? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
