gnodet opened a new pull request, #22975: URL: https://github.com/apache/camel/pull/22975
[CAMEL-23247](https://issues.apache.org/jira/browse/CAMEL-23247) Fix the flaky `MailContentTypeResolverTest.testCustomContentTypeResolver` test that intermittently fails with: ``` expected: <Hello World> but was: <jakarta.mail.internet.MimeMultipart@...> ``` **Root cause**: There is a race condition between the test assertion thread and the POP3 consumer's polling thread. When the consumer delivers the exchange to the mock endpoint, the test thread wakes up from `assertIsSatisfied()` and runs assertions. Meanwhile, the consumer thread continues to run `processCommit` and then closes the mail folder in the `poll()` finally block. If the folder closes before `getBody(String.class)` converts the `MimeMultipart` body, the `MailConverters.toString(Multipart)` converter fails to access the multipart parts, returns null, and the fallback `Object.toString()` produces the `MimeMultipart@...` string. **Fix**: Add `.convertBodyTo(String.class)` in the route to eagerly convert the `MimeMultipart` body to a `String` during route processing, while the mail folder is still open. This follows the same pattern used by other mail tests (`MailRouteTest`, `MimeMessageConsumeTest`, `NestedMimeMessageConsumeTest`). The attachment assertions are unaffected since attachments are extracted separately by the `MailConsumer` before route processing. Verified with 10 consecutive test runs — all passed. -- 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]
