yuvalif commented on PR #3026: URL: https://github.com/apache/camel-kamelets/pull/3026#issuecomment-5663294610
@oscerd thanks for doing that! > ## Open question for @yuvalif > The Ceph extension fields — `s3.bucket.id`, `s3.object.metadata`, `s3.object.tags`, and the record-level `eventId` and `opaqueData` — are passed through in the body but not surfaced as headers. `eventId` in particular is documented as usable for acking, so it would make a natural idempotency key. Happy to add them as headers in a follow-up if that is useful; I did not want to guess at which ones matter. > > _Claude Code on behalf of Andrea Cosentino_ most of these extensions would be useful * `s3.object.metadata` this is user information added as attributed on the object. in Ceph you can use these attributes for notification filtering. in addition, if the kamelet is used in order to consume these events into a database (or a catalog system), metadata could be useful * `s3.object.tags`: similar to metadata but more structured * `eventId`: would be used for finding duplicate events. this may happen due to retransmits in case of kafka disconnects * `opaqueData`: extra user info associated with the topic. used for customizations that we could not predict beforhand. from my experience, used very creatively by users to work around issues :-) * `s3.bucket.id` - probably not needed. this is an internal ceph ID of the bucket. useful for debugging (if you delete a bucket and create it with the same name, it will have a different ID) -- 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]
