-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event Domain doesn't support a CloudEvents v 1.0 #43468
Comments
@romankiss Thank you for your feedback! We will review and update as appropriate. |
cc: @banisadr |
I also observe this. The documentation doesn't make clear what attribute of a CloudEvents message corresponds to |
Any update on this? This issue makes it very hard to use CloudEvent schema. It is also undocumented that the |
Six months since it was raised. Seems to be related to Azure/azure-sdk-for-net#10684 @jfggdl is this something on the radar? |
I noticed that you can now specify the field that maps to topic when creating the Event Grid Domain. I added a custom field called |
Thanks @romankiss and @SeanFeldman. We are doing our backlog grooming and we will prioritize this ask. @ahamad-MS or someone else from our team can start providing some information about what is supported. We will also fix any resulting documentation issues. |
#reassign:ahamad-MS |
ahamad-MS is already assigned. |
@ahamad-MS - could you review and add your input here? Thanks! |
@romankiss ... CloudEvent support was recently added in the new generation of SDK https://www.nuget.org/packages/Azure.Messaging.EventGrid/4.0.0-beta.2 . Please confirm you no longer have this issue. |
@ahamad-MS - The issue is still there such as in the AEG domain implementation. My comment was not related to the SDK. This issue can be duplicated posting the event to the domain event endpoint via the REST: Payload (example from the CloudEvent spec 1.0:
response:
another example: when the source property has a simple string value (internally name of the topic), then the request is passed, see the following example: Thanks |
@ahamad-MS - please review the latest post from Roman as soon as you can. Thank you. |
@romankiss we are investigating this issue and will update the thread with findings. However, as a general comment, this is not a real document bug and fit better as service issue. Please use user voice or open a support ticket to handle similar issues in the future. Thanks |
@romankiss - Appreciate if you could submit an idea on User Voice(https://feedback.azure.com/forums/909934-azure-event-grid), or open a support ticket for @ahamad-MS to investigate further. Thank you. @ahamad-MS - please feel free to reopen the issue if you want to add any information. Thanks. #please-close |
Is there any movement on this. It is confusing to consumers to be subscribing to a topic, named identify a boundary for an audience of subscribers but uses "Source" concept in CloudEvents to map that event to a topic. Seems like source and destination concepts are being used here. Referring to MSFT documentation for cloud event source., states for source property "Gets or sets the context in which an event happened" - so this is event centric statement. In this doc, topics are described as a boundary for subscriptions.. My consumers are asking why the source property contains the topic name (in our case their Partner ID just like the MSFT example). |
Anyone is aware if a request has been made on User Voice for Event Grid regarding this issue?. If such a request exists, could you please provide the link to it? Thanks! |
Consuming a CloudEvents by the AEG event domain endpoint failed at the source attribute.
For example:
will generate the following error:
The another compatibility issue with a CloudEvents v 1.0 is using a batching for single event, in other words, the event domain didn't allow to consume a single event message (JObject), it must be wrapped by array.
For EventGridSchema we can use a topic property for domain topic, but for consuming the CloudEvents messages from any producer, the source attribute should be flowed to the subscriber via filtering without any modification. In other words, the domain topic can not be hardcoded to the source attribute such as an URI-reference type, for examples:
Thanks
Roman
Update
Using a batching vs single CloudEvents v1.0 events is working well for custom topic and also for event domain. It is based on the Content-Type header such as
or
The compatibility issue when the CloudEvents v1.0 is used can be simple tested within the AEG in the following cases (cascading events, for example: blob storage -> custom/domain topic):
subscribing a custom topic for delivery and input = CloudEventSchemaV1_0
subscribing an event domain for delivery and input = CloudEventSchemaV1_0
Note, that the case 1 will work very well included a validation handshaking, but in the case 2, the validation is passed, but every Notification events will failed for reason a source attribute.
Another incompatibility with the CloudEvents v1.0 is that the request is not validate for required attributes of the CloudEvents schema and basically can be used only the following attributes, for example:
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: