oscerd opened a new issue, #2957:
URL: https://github.com/apache/camel-kamelets/issues/2957
Two Kamelets declare inbound header mappings that never take effect.
**1. `mail-sink` — `ce-*` mappings are ignored by camel-mail**
The template maps CloudEvent headers onto the mail headers:
```yaml
- choice:
when:
- simple: "${header[ce-subject]}"
steps:
- setHeader:
name: Subject
simple: "${header[ce-subject]}"
# ... same for ce-from -> From, ce-to -> To, ce-cc -> Cc
```
But `camel-mail` only honours the `Subject`, `From`, `To` and `Cc` headers
when the corresponding options are enabled, and in Camel 4.22.0 all of them
default to `false`:
| option | default |
|---|---|
| `useHeaderSubject` | `false` |
| `useHeaderFrom` | `false` |
| `useHeaderRecipients` | `false` |
| `useHeaderReplyTo` | `false` |
`mail-sink` sets none of them, so the four mappings are dead code — the
endpoint's `{{subject}}`, `{{from}}` and `{{to}}` properties always win. Either
the template should set the `useHeader*` options it needs (ideally behind a
declared, default-off property so the behaviour is opt-in and visible), or the
dead mappings should be removed.
**2. `redis-sink` — one-character mismatch**
```yaml
- simple: "${header[ce-channel]}" # line 114 — condition
...
simple: "${header[ce-channell]}" # line 118 — value (typo)
```
The condition tests `ce-channel` but the value reads `ce-channell`, so the
branch fires and then sets an empty channel. `ce-channell` appears nowhere else
in the catalog.
The same file also has `value`/`message` mappings that are unconditionally
overwritten after the `choice` blocks; worth cleaning up in the same change.
Related: #929.
_Claude Code on behalf of Andrea Cosentino_
--
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]
