Error Notification

[CxRes]

In case the channel is not able to generate a notification upon an event, say, due to an error, it should instead send a standardized error notification.

We need to decide when error notifications are generated and what this error notification looks like.

[elf-pavlik]

Can you give an example or multiple examples of how the Notification Receiver would act when it receives that error notification?

[CxRes]

That's up to the notification receiver.

Notification receiver, may continue to receive notifications. Or it may disconnect and try to re-establish connection.

The alternative is that the server terminates the connection upon such errors, but that would be discourteous.

[csarven]

See also solid/specification#28

[CxRes]

Anything specific that you want to point to from those issue, other than:

1. Error should be RDF
2. It should not disclose reason for the server error.

[csarven]

Right, that's in a nutshell. The other part is about if this is pursued, it'd probably serve more cases with a common language.

[elf-pavlik]

As for concrete examples, what information would the notification sender miss? I assume it would always know the topic, but it may miss the latest state. Would it be some general notification system failure, and all channels would get a broadcast that they need to make something to ensure eventual consistency?

I think we should start with a few concrete scenarios and address them, keeping things generic as much as possible.

[CxRes]

Concrete examples will be too many to enumerate and never be exhaustive.

However, I propose we evaluate failures modes in terms of classes of products:

This brings us to these cases:

1. Resource server fails to communicate events to Notification Sender (nothing to be done here but sender could still infer an error upon the next communication).
2. Resource Server reports an event to the Notification Sender, but is unable to generate information about the event or communicates an error.
3. The communication between Resource Server and Notification Sender breaks down mid-way. Notification Sender can infer an event but does not know what it is.
4. Notification Sender fails to generate the notification due to a middleware error, and is able to send a generic notification instead.

So both the cases @elf-pavlik mentions are possible. Rather than worry about what caused an error, the protocol's job is to address what to convey when an error occurs, so that receivers can implement their own mitigation strategies. A bit like 5xx codes in HTTP. The main goal is to ensure that clients have enough information to select that mitigation strategy, without revealing the private details of the server.

[CxRes]

I would prefer if we can sort this over a discussion (with notes), instead of having to hash all the details out in the issues, if this is acceptable to the other participants?