[
https://issues.apache.org/jira/browse/JAMES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472805#comment-17472805
]
Jean Helou commented on JAMES-3696:
-----------------------------------
The tests actually already account for the eventual consistency of the filter
propagation, they include a call to `awaitRemove()` which is empty for most
implementations and is defined as
{code:java}
@Override
public void awaitRemove() {
try {
Thread.sleep(100);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
} {code}
in PulsarMailqueueTest
What likely happens is that 100ms is too little for the CI plateform, there are
2 options:
- change all the assertions on remove to use awaitility
- increase the wait time (if possible only on CI, we could try to resolve the
CI env variable and conditionnaly have a larger wait time)
> Solve instable test for the pulsar mail queue
> ---------------------------------------------
>
> Key: JAMES-3696
> URL: https://issues.apache.org/jira/browse/JAMES-3696
> Project: James Server
> Issue Type: Sub-task
> Components: pulsar, Queue
> Affects Versions: master
> Reporter: Benoit Tellier
> Priority: Major
> Labels: bug
>
> https://ci-builds.apache.org/job/james/job/ApacheJames/job/PR-826/7/
> Pulsar mail queue bringed in some unstable tests
> {code:java}
> Test Result (4 failures / +4)
>
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeByRecipientShouldRemoveSpecificEmail
>
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeByRecipientShouldRemoveSpecificEmailWhenMultipleRecipients{List,
> MailAddress}[5]
>
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeByRecipientShouldRemoveSpecificEmailWhenMultipleRecipients{List,
> MailAddress}[6]
>
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeShouldRemoveMailFromStoreWhenFilteredOut
> {code}
> Looking at the first, some email expected to be deleted were not:
> {code:java}
> Error Message
> Expecting actual:
> ["name1", "name2"]
> to contain exactly (and in same order):
> ["name1"]
> but some elements were not expected:
> ["name2"]
> {code}
> Maybe because propagation of the delete filter is asynchronous? (IE the
> client delete returns when enqueuing the filter but without any warranty so
> as when it would be dequeued and applied). If so this isa design flaw and I
> hardly see how to improve that .
> Or we add a delay in the tests to relax the consistency guaranty?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
