Allow users to signal whether extensions are required

[lailabougria]

Use case: From a producer-perspective, I want to avoid poison messages being produced due to missing attributes that are required in the system (either by intermediaries or consumers). This should be handled as a cross-cutting concern, to avoid gaps.

Currently, the SDK allows extensions to be created, and it allows users to provide a validator to execute.

The validator method can be used to ensure the type, structure, or even combination of extensions that should be set, providing full validation of the extension. However, it doesn't allow users to indicate that it is a required extension.

Taking the example of a tenant attribute that is required within the system's boundaries, I could register the attribute as follows:

var tenantIdAttribute =
    CloudEventAttribute.CreateExtension("tenant", CloudEventAttributeType.String, tenantValue =>
    {
        if (tenantValue is not string tenant) throw new ArgumentException("tenant attribute must be of type string");

        if (string.IsNullOrWhiteSpace(tenant))
            throw new ArgumentException("tenant attribute must not be null, empty or whitespace");
    });

However, the validation only runs if the attribute is actually set, but from a user's perspective, the ability to indicate this as a required extension is equally important. Currently, the SDK allows me to tackle extension validation as a cross-cutting concern by providing a validation method to the SDK, however, it currently neglects what may be most essential to many users, verifying that the attribute is actually there.

[jskeet]

Eek, I apologise for not responding on this - I hadn't even seen it until just now for some reason. Will respond properly tomorrow.

[jskeet]

I'm torn on this. On the one hand, I can see the appeal of putting it on the extension. On the other hand, I tend to jealously guard API surfaces. It feels like you'd need to make sure you pass the attribute in wherever you're serializing/deserializing the event, so if you've centralized that logic, you could put the validation there.

As an alternative idea, how about I introduce a decorator CloudEventFormatter that could:

• Accept another CloudEventFormatter to delegate to
• Perform arbitrary validation on both serialization and deserialization (either via inheritance or passing in some sort of validator)
• Perhaps have the built-in ability to provide a set of extensions

I think that would probably still solve your concern, but also solve other validation use cases.

If that sounds like it might be feasible, I can whip up a prototype PR to explore API options.

[lailabougria]

It sounds like that would indeed address the concern so I look forward to seeing a proposal!