oscerd opened a new pull request, #3030: URL: https://github.com/apache/camel-kamelets/pull/3030
Re-lands work that **missed the merge of #3026**. That PR was merged at its first commit, so the header change never reached `main` — `grep ceph-event-id kamelets/ceph-event-based-source.kamelet.yaml` returns nothing there today. Stacked on #3029 (the description one-liner change), since both touch this Kamelet and the extension documentation belongs in the partial that PR creates. Merge that one first. ## What it adds Following @yuvalif's field-by-field guidance on #3026: | field | header | his reasoning | |---|---|---| | `s3.object.metadata` | `ceph-object-metadata` | user attributes; Ceph can filter notifications on them, and they matter feeding a catalog or database | | `s3.object.tags` | `ceph-object-tags` | same but more structured | | `eventId` | `ceph-event-id` | spotting duplicates after a Kafka retransmit | | `opaqueData` | `ceph-opaque-data` | user information attached to the topic | `s3.bucket.id` deliberately left out — he called it an internal id, useful for debugging only. Each gets a `ce-` CloudEvents counterpart, which is how this catalog names source output headers; `infinispan-source` and `ftp-source` both do the plain-plus-`ce-` pair. ## Verified ``` id=[evt-12345] opaque=[[email protected]] meta=[[{key=x-amz-meta-owner, val=alice}]] tags=[[{key=env, val=prod}]] ce-id=[evt-12345] ``` `metadata` and `tags` arrive as structured lists rather than flattened strings. `script/validator` reports no errors and `mvn clean install` passes with tests from the repository root. ## Two behaviours recorded in the partial **An empty `eventId` is possible.** The event structure in the Ceph documentation carries `"eventId":""`, and with that payload the header is set but blank: ``` EDGE id=[] opaque=[] meta=[[]] tags=[[]] ``` Anyone deduplicating on it would get a header that is always equal and silently dedupe nothing, so the partial says so. I have asked @yuvalif on #3026 whether it is populated in practice and what it depends on; if the answer is version- or configuration-specific, the wording should tighten. **Foreign messages now fail.** Reading the `Records` array means a message that is not a Ceph notification fails the exchange: ``` PathNotFoundException: Missing property in path $['Records'] ``` Previously, with `getObject` off, anything passed through untouched. I kept the strict behaviour on purpose — emitting blank Ceph headers for foreign messages would be worse than failing — and the partial states that the topic is expected to carry only Ceph notifications. --- _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]
