CAMEL-24344: camel-google-mail - return a body for raw and non-multipart messages - #25357
CAMEL-24344: camel-google-mail - return a body for raw and non-multipart messages#25357oscerd wants to merge 2 commits into
Conversation
…art messages The stream consumer always asked the Gmail API for the FULL message format, but the raw field is only populated for the RAW format, so raw=true always produced a null body. The consumer now asks for the format matching the option. The non-raw path only looked at the first element of getParts(), so a message that is not multipart - which carries its content directly on the payload - was delivered without a body, and a nested multipart yielded nothing either. The body is now taken from the first part carrying data, walking into nested parts. The payload and its header list are also no longer dereferenced without a check, and a failed exchange no longer marks the mail as unread when markAsRead was not enabled in the first place. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
| protected void processRollback(Exchange exchange, String unreadLabelId) { | ||
| if (!getConfiguration().isMarkAsRead()) { | ||
| // the mail was never marked as read, so there is nothing to roll back | ||
| LOG.warn("Exchange failed: {}", exchange); |
There was a problem hiding this comment.
why are we WARN logging here when this method is about marking the mail as un-read, and this is an early exit to not do that, so I would assume this LOG should be removed
davsclaus
left a comment
There was a problem hiding this comment.
Nice fix — the three bugs are well identified and the upgrade guide entry is clear.
One minor finding in the new test; everything else looks good.
This review was generated by an AI agent on behalf of davsclaus and may contain inaccuracies. Please verify all suggestions before applying.
| context.start(); | ||
| GoogleMailStreamEndpoint endpoint = context.getEndpoint( | ||
| "google-mail-stream://index?clientId=id&clientSecret=secret&raw=" + raw, | ||
| GoogleMailStreamEndpoint.class); |
There was a problem hiding this comment.
Minor resource leak: theRawOptionAsksForTheRawFormat calls consumer() twice — the first call creates and starts a DefaultCamelContext, then the second call overwrites this.context without stopping the first one. The orphaned context is never cleaned up by @AfterEach.
Suggestion — stop any previous context before creating a new one:
| GoogleMailStreamEndpoint.class); | |
| private GoogleMailStreamConsumer consumer(boolean raw) throws Exception { | |
| if (context != null) { | |
| context.stop(); | |
| } | |
| context = new DefaultCamelContext(); |
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 10 tested, 28 compile-only — current: 9 all testedMaveniverse Scalpel detected 38 affected modules (current approach: 9).
|
…ious test context Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
|
Both points addressed in the follow-up commit:
Claude Code on behalf of oscerd |
Three body-related defects in the
google-mail-streamconsumer.1.
raw=truealways produced anullbody. The consumer asked for theFULLformat:but Gmail only populates
rawforformat=RAW(API reference:
"Returned in messages.get and drafts.get responses when the format=RAW parameter is supplied.").
The requested format now follows the option.
Since the
RAWformat does not return the parsedpayload, a route withraw=trueno longer getsthe subject/from/to/cc/bcc/message-id headers — they are part of the RFC 2822 content that is now in
the body. That is covered by an upgrade-guide entry.
2. Messages that are not multipart arrived with no body. The old code only looked at
getPayload().getParts(), which isnullfor a plain message — its content sits directly onpayload.body.data. Nested multiparts (amultipart/mixedinside amultipart/alternative) werealso skipped, because
parts.get(0).getBody().getData()isnullfor a part that only holds otherparts. The body is now taken from the first part that actually carries data, descending into nested
parts.
3.
getPayload()andgetPayload().getHeaders()were dereferenced unguarded — both are absentfor some message formats and metadata-only responses.
Also:
processRollbackre-added theUNREADlabel even whenmarkAsReadwas never enabled, so afailed exchange mutated the mailbox for routes that had not asked for it; and its catch block
reported "Error occurred mark as read mail" for a rollback failure.
Claude Code on behalf of oscerd
🤖 Generated with Claude Code