Addressed comments

Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
open-telemetry · Jun 5, 2023 · e45443d · e45443d
1 parent 3b68677
commit e45443d
Show file tree

Hide file tree

Showing 2 changed files with 10 additions and 6 deletions.
diff --git a/.chloggen/propagate-errors.yaml b/.chloggen/propagate-errors.yaml
@@ -5,12 +5,12 @@ change_type: 'enhancement'
 component: otlpreceiver
 
 # A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
-note: Propagate errors from the exporter back to the caller
+note: Propagate HTTP errors from the exporter back to the caller
 
 # One or more tracking issues or pull requests related to the change
 issues: [7486]
 
 # (Optional) One or more lines of additional information to render under the primary note.
 # These lines will be padded with 2 spaces and then inserted directly into the document.
 # Use pipe (|) for multiline entries.
-subtext: The Collector can now propagate errors from backends to the client when used as a simple gateway.
+subtext: The Collector can now propagate errors from backends to the client when used as a proxy.
diff --git a/internal/colerrs/README.md b/internal/colerrs/README.md
@@ -7,11 +7,15 @@ backends.
 
 Error propagation only works when there's synchronous processing of a pipeline.
 Concretely, this means there should be no batch processors, sending queues for
-exporters and other resiliency mechanisms should be disabled.
+exporters and potentially other resiliency mechanisms should be disabled. When
+the pipeline is async, as it is the case when the batch processor is part of it,
+the errors being returned by the backends used by the exporters are returned
+only after the Collector's client has received its response already.
 
-"Asymmetrical" processors (e.g. Anything that merges, splits, reorganizes,
-drops, or adds ptraces/pmetrics/plogs) shouldn't also be included in the
-pipeline.
+Processors doing data transformation should be treated with care, perhaps even
+avoided for sync pipelines. The reason is that when a failure happens _because_
+of those transformations, the Collector's client isn't at fault: a 400 returned
+by a backend should NOT propagate back to the client.
 
 Shared receivers might also fail in different ways than the outcome of the
 exporters.