Remove unnecessary condition to have at least one processor

config/config.go

@@ -781,14 +781,8 @@ func validatePipelineProcessors(
 	pipeline *configmodels.Pipeline,
 	logger *zap.Logger,
 ) error {
-	if pipeline.InputType == configmodels.TracesDataType {
-		// Traces pipeline must have at least one processor.
-		if len(pipeline.Processors) == 0 {
-			return &configError{
-				code: errPipelineMustHaveProcessors,
-				msg:  fmt.Sprintf("pipeline %q must have at least one processor", pipeline.Name),
-			}
-		}
+	if len(pipeline.Processors) == 0 {
+		return nil
 	}
 
 	// Validate pipeline processor name references

config/config_test.go

@@ -366,7 +366,6 @@ func TestDecodeConfig_Invalid(t *testing.T) {
 		{name: "pipeline-must-have-receiver", expected: errPipelineMustHaveReceiver},
 		{name: "pipeline-exporter-not-exists", expected: errPipelineExporterNotExists},
 		{name: "pipeline-processor-not-exists", expected: errPipelineProcessorNotExists},
-		{name: "pipeline-must-have-processors", expected: errPipelineMustHaveProcessors},
 		{name: "unknown-extension-type", expected: errUnknownExtensionType},
 		{name: "unknown-receiver-type", expected: errUnknownReceiverType},
 		{name: "unknown-exporter-type", expected: errUnknownExporterType},

docs/design.md

@@ -110,8 +110,6 @@ In the above example “jaeger” exporter will get data from pipeline “traces
 
 A pipeline can contain sequentially connected processors. The first processor gets the data from one or more receivers that are configured for the pipeline, the last processor sends the data to one or more exporters that are configured for the pipeline. All processors between the first and last receive the data strictly only from one preceding processor and send data strictly only to the succeeding processor.
 
-The traces pipeline must have at least one processor. Metrics pipeline does not require processors since we currently do not have any implemented metrics processors yet.
-
 Processors can transform the data before forwarding it (i.e. add or remove attributes from spans), they can drop the data simply by deciding not to forward it (this is for example how “sampling” processor works), they can also generate new data (this is how for example how a “persistent-queue” processor can work after Collector restarts by reading previously saved data from a local file and forwarding it on the pipeline).
 
 The same name of the processor can be referenced in the “processors” key of multiple pipelines. In this case the same configuration will be used for each of these processors however each pipeline will always gets its own instance of the processor. Each of these processors will have its own state, the processors are never shared between pipelines. For example if “queued_retry” processor is used several pipelines each pipeline will have its own queue (although the queues will be configured exactly the same way if the reference the same key in the config file). As an example, given the following config: