-
Notifications
You must be signed in to change notification settings - Fork 0
sns: properties dropped between CDK and the emulator #522
Copy link
Copy link
Closed
Labels
area/emulationAWS-compatible service behavior, handlers, wire formats, SDK compatibility, and state transitionsAWS-compatible service behavior, handlers, wire formats, SDK compatibility, and state transitionsaws-fidelityRequires matching AWS request, response, error, validation, or lifecycle behavior.Requires matching AWS request, response, error, validation, or lifecycle behavior.enhancementNew feature or requestNew feature or requestpriority/p1High priority workHigh priority workservice/cloudformationWork for the cloudformation service emulatorWork for the cloudformation service emulatorservice/snsWork for the sns service emulatorWork for the sns service emulatorstatus/doneComplete and ready to close or already completeComplete and ready to close or already complete
Description
Metadata
Metadata
Assignees
Labels
area/emulationAWS-compatible service behavior, handlers, wire formats, SDK compatibility, and state transitionsAWS-compatible service behavior, handlers, wire formats, SDK compatibility, and state transitionsaws-fidelityRequires matching AWS request, response, error, validation, or lifecycle behavior.Requires matching AWS request, response, error, validation, or lifecycle behavior.enhancementNew feature or requestNew feature or requestpriority/p1High priority workHigh priority workservice/cloudformationWork for the cloudformation service emulatorWork for the cloudformation service emulatorservice/snsWork for the sns service emulatorWork for the sns service emulatorstatus/doneComplete and ready to close or already completeComplete and ready to close or already complete
Part of the repo-wide sweep for properties that arrive from CDK/CloudFormation and are parsed into nothing.
Priority 1 — SNS implements it, CloudFormation never passes it
snsSubscriptionHandler.Create(internal/services/cloudformation/provisioner.go:2132) sends onlyTopicArn,Protocol,EndpointtoSubscribe. Every subscription attribute is dropped:FilterPolicyhandler_publish.go:337-342evaluates it per subscription;messageMatchesFilterPolicyathandler_publish.go:719FilterPolicyScopeRawMessageDeliveryhandler_publish.go:67documents the lambda exclusion, matching AWS)RedrivePolicycapabilities_dev.go:22)DeliveryPolicy,SubscriptionRoleArnSetSubscriptionAttributes, which accepts any attributeSo
topic.addSubscription(new SqsSubscription(queue, { rawMessageDelivery: true, filterPolicy: {...} }))deploys clean, and then every message is delivered to every subscriber in SNS envelope format. The filtering code is there and working; nothing ever populates the attribute it reads.AWS::SNS::Topic
snsTopicHandler.Create(provisioner.go:2092) callsCreateTopicwithNameonly.DisplayNameandKmsMasterKeyIdare applied viaSetTopicAttributesinUpdateonly (provisioner.go:2079-2088). On the initial deploy they are silently lost; they appear only if the stack is later updated. That asymmetry is a bug on its own.FifoTopic,ContentBasedDeduplication,Tags,Subscription(the inline subscription list — a template that declares subscriptions inline creates none),DeliveryPolicy,SignatureVersion,TracingConfig,ArchivePolicy,DataProtectionPolicy.FifoTopichas no emulation behind it either (no FIFO topic handling ininternal/services/sns/), so that one is echo fidelity — but it should still round-trip rather than vanish.Suggested order
SetSubscriptionAttributesafterSubscribeforFilterPolicy,FilterPolicyScope,RawMessageDelivery,RedrivePolicy. This turns working code back on.DisplayName/KmsMasterKeyIdintoCreateas well asUpdate.Subscriptionlist onAWS::SNS::Topic.Definition of done
tests/integration/cloudformation/: provision a topic with a filtered, raw-delivery SQS subscription, publish a non-matching and a matching message, assert only the matching one arrives and that it is raw.GetSubscriptionAttributesafter a stack deploy agrees with the template.Related: #183, #185.