Dead-Letter Queue or other Error Handling

[alexander-alvarez]

Problem
Brokers forward events to subscribers which in turn route traffic to revisions. Knative can work properly and get these events to the proper revision handler that is running correctly, but the execution of the events can fail for a variety of reasons (downstream system is down, application logic rejects the invalid message, a runtime exception occurs, etc) but right now there is no way to control or define the expected behavior in these situations.

Persona:
Event Consumer / System integrator

Exit Criteria

• An event consumer can define a configuration that indicates when a message fails / exceeds the retry back-off in a service, the given message is considered "dead" and can be routed to another channel (for the eventual handing by another service: the "dead-letter handler")
  • Possibly implemented as an abstraction similar to Sequence is where try-catch functionality is provided, allowing a branching pattern with successful events going down one branch and unsucessful ones going down another

Time Estimate (optional):
I have no idea since I'm not familiar with the codebase

Additional context (optional)
N/A

[lionelvillard]

This is an important pattern and there is a beginning of a solution in the context of Choice, which needs to be generalized to other Composable objects (like Sequence).

[mikehelmick]

related to #1555

[nachocano]

@lionelvillard have you started with some of this work? I'd be happy to help/collaborate... And also on #1493. IIRC @Harwayne mentioned you guys have started discussing this in the Channel task force group?

[lionelvillard]

I haven't started other than thinking about how to do it.

Regarding retrying (#1493), what about adding this capability into the CloudEvent SDK? @n3wscott any thoughts on that?

[akashrv]

/milestone v0.9.0

[nachocano]

/assign

[nachocano]

/unassign
as I'm not actively working on this...
just in case someone wants to grab it

[lionelvillard]

I'll grab it in about 3 weeks, unless someone wants to take a look at it before.

[mikehelmick]

@rgregg - This needs requirements / product input.

[aslom]

I am also interested in this. Let start on design/requirement document

using template:
https://docs.google.com/document/d/1QRREfL8gSVSURHMkDLjDtMh1BBsNiwfmaBiGnJUDQ2g/edit
via 0.9 plan
https://docs.google.com/document/d/1iR9Vfmgi1Dkf_ge95LXA-VdZ3shV0611C3vtIF6-7c4/edit#heading=h.ltzumxehvfdz

[rgregg]

We need to follow the Knative Feature Tracks template that @aslom linked to. Before we start writing code, someone with the insights on what we need to do here needs to complete steps 1 & 2 for review. Step 1 may be covered by the original text of this issue, but the need for a design doc that we can review seems clear here.