Repository navigation
Description
Is your feature request related to a problem? Please describe.
Currently, when creating a CloudEvent instance, one of the final things that happens in the constructor before freezing the object is this.validate() is called. The validate() function will throw an exception if the event is invalid. This effectively means that there is no way to create an event that's invalid. In most cases, this is probably for the best. But what happens if you have a system with a known bug that's emitting invalid events, and some JavaScript service using this module is receiving them. There's no way to actually do that without forking this repo.
Describe the solution you would like to see
- Optionally, don't call
this.validate()in the constructor based on an addedbooleanparameter (strict: boolean = trueby default). - Change
Detectorinterface from feat: introduce Message, Serializer, Deserializer and Binding interfaces #324 to use an optional parameter for loose validation. - Change the
Deserializerinterface which converts from aMessageto aCloudEventto use an optional parameter for loose validation.
Additional context
This is all in the context of creating events manually, or deserializing an incoming Message into a CloudEvent. I haven't thought much about the serialization step. If a user manually creates an invalid event, and then serializes it to a Message, should that throw an exception? I think maybe it should, but interested in other's opinions.
Activity
lholmquist commentedon Aug 25, 2020
When i was first adding the validation to the CloudEvent constructor, i contemplated adding what you are talking about in. My main reason was because of how the test were written.
I can see this being a feature, but my only concern is if a user has a service where they send cloud events, and turn off the event validation. then another user uses that service to receive events, how will they know that the service has the validation turned off. They will probably get errors when trying to "accept" the event and think that maybe there is a bug in this library.
feat: add a constructor parameter for loose validation
grant commentedon Aug 26, 2020
Thanks for creating the issue!
According to the SDK spec, there are various methods described. One of them is creation and one is validation.
https://github.com/cloudevents/spec/blob/master/SDK.md#technical-requirements
I would assume the composition method and validation method are separate and folks can use them separately as they wish for whatever reason they want.
As such, I think the validation method should not be called by default within the composition method. (Maybe we can have it for convenience.) It should be default
false. This is important because consumers of CloudEvent from major CE producers can expect to have a valid event and don't need this.i.e. we don't need
new CloudEvent({...}, false)everywhere.feat: add a constructor parameter for loose validation
feat: add a constructor parameter for loose validation (#328)
feat: add a constructor parameter for loose validation (cloudevents#328)
feat: add a constructor parameter for loose validation (#328)
3 more commits for the backport (#2)
feat: add a constructor parameter for loose validation (cloudevents#328)
feat: add a constructor parameter for loose validation (#328)