MTChannelBroker: Enhance failed events with extra metadata

[matzew]

If a message is routed to the deadletter sink of the MTChannelBroker or its Triggers, there is no contextual information on why the message landed there.

In a few Knative components, we have some metadata for this:

• For the Knative Channels: https://knative.dev/docs/eventing/event-delivery/#configuring-channel-event-delivery
• For the KnativeKafkaBroker: Knative error extensions knative-extensions/eventing-kafka-broker#2374

Would be nice if the reference implementation of the MTChannelBroker would have this feature too

[liuchangyan]

/assign

[lionelvillard]

We may want to go further by standardizing these attributes and adding them to the knative spec.

@gab-satchi @gabo1208 WDYT?

[liuchangyan]

Hi, I am working on adding "knativeerrordest knativeerrorcode knativeerrordata" extensions on MTchannelBroker,
Most of the data in MTchannelBroker is processed by Channels:
In Control-Plane of MTchannelBroker, mt-broker-controller create subscription according to the information of the trigger, this subscription contains the address of subscriber(broker-filter) and the information of Broker, like this example:

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: default-trigger1-3f6e7a8e-f7d1-4c8f-a25a-1970b6ab73e3
  namespace: default
spec:
  channel:
    apiVersion: messaging.knative.dev/v1beta1
    kind: NatssChannel
    name: default-kne-trigger
  reply:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: default
      namespace: default
  subscriber:
    uri: http://broker-filter.knative-eventing.svc.cluster.local/triggers/default/trigger1/3f6e7a8e-f7d1-4c8f-a25a-1970b6ab73e3

So in the entire data flow, the path of event message is channel->broker-filter->target; and the path pf response is target->broker-filter->channel, and the extention "knativeerrordest" what we got is broker-filter's URI, but what we need is actual trigger's URI.

Based on this situation, there are two methods that we could get trigger's URI:

Method 1: In broker-filter, we could add a pair of key value in response body to store trigger's URI. After getting response Channel could unmarshal this URI when the destination is broker-filter.

Method 2: We could add processing logic about deadlettersink in broker-filter when sending error is not nil , do the same like Channel.

Which one is better? is there any other methods and what do you think? @pierDipi @matzew