[
https://issues.apache.org/jira/browse/JAMES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17472817#comment-17472817
]
Benoit Tellier commented on JAMES-3696:
---------------------------------------
awaitility won't cut it as "if the mail is dequeued prior the filter applies"
we won't converge to the desired time.
I agree increasing wait time. 100ms seems optimistic. 500ms would seems great
to me.
> (if possible only on CI, we could try to resolve the CI env variable and
> conditionnaly have a larger wait time)
This makes build profiles harder to grasp, issues harder to reproduce. Could
also be seen as an entry barreer to people running the build for the first time
on slow environments.
> 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]
