IntegrationSink SNS messages are missing core Cloud Event attributes

[darkgnotic]

Describe the bug

SNS messages created by the IntegrationSink (sns option) are missing core Cloud Event attributes (id, type, subject, time, etc.). Extension attributes, on the other hand, are preserved.

Expected behavior

The MessageAttributes of the produced SNS message should contain all Cloud Event attributes.

To Reproduce

Use the IntegrationSink with the sns option.

Knative release version

v0.19.0

Additional context

The HTTP headers by default have the CamelCloudEvent prefix for core attributes, and the Ce- prefix for extension attributes, e.g.

CamelCloudEventID=2d07a084-e0d0-4bc9-9724-8bcff8360f5a
CamelCloudEventSource=https://10.100.0.1:443
CamelCloudEventSubject=/apis/apps/v1/namespaces/foo/deployments/bar
CamelCloudEventTime=2025-09-15T15:20:30.182762705Z
CamelCloudEventType=dev.knative.apiserver.resource.delete
CamelCloudEventVersion=1.0
CamelHttpMethod=POST
CamelHttpPath=
CamelHttpQuery=null
CamelHttpUri=/
Ce-Apiversion=apps/v1
Ce-Kind=Deployment
Ce-Knativearrivaltime=2025-09-15T15:20:30.183022734Z
Ce-Name=bar
Ce-Namespace=foo
Content-Length=10929
Content-Type=application/json
Host=cluster-events-log-sink-service.events.svc.cluster.local
Kn-Namespace=events
Prefer=reply
User-Agent=Go-http-client/1.1

The apiversion, kind, knativearrivaltime, name, and namespace extension attributes all appear the SNS MessageAttributes, but the id, source, subject, time, and type do not.

I believe the core attributes are filtered because the Sns2HeaderFilterStrategy filters out any headers that start with Camel, which includes not only internal headers like the CamelHttp* headers, but the CamelCloudEvent* headers as well.

It's possible that the sink needs to be configured with a CloudEventHttpDataTypeTransformer to convert those header names to their ce-* equivalents before being handed off to the SNS logic, but I have not studied the code enough to be 100% sure.

[christophd]

Thank you for the detailed error analysis. I think you are totally right with the header filter. I am looking into it for a fix ...

[darkgnotic]

Something else to put on your radar; once the core headers are being processed by the aws2-sns logic, there is a bug in that component in which it directly uses the Cloud Event subject as the SNS subject, and the latter is subject to a 100 character limit, whereas the former is not.

https://issues.apache.org/jira/browse/CAMEL-22429

So once core events attributes are working, users may then trip over the long subject bug until it is fixed in the Camel component.

Not sure if it is worth working around on the knative side or not, but just letting you know!

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[creydr]

/remove-lifecycle stale @christophd did you have a chance to look into it?