Allow partial retries in queued retry processor

[pavolloffay]

Signed-off-by: Pavol Loffay ploffay@redhat.com

Description: <Describe what has changed.

This patch allows partial retries in queued_retry processor. The following consumer after the retry processor initializes partial retry by returning an error type that encapsulates data that should be retried. When a different error type is returned the processor retries the original data set.

This PR does not contain any breaking changes nor change of the current behavior of the queued_retry processor.

Link to tracking Issue:

Resolves #990

Testing: < Describe what testing was performed and which tests were added.>

Documentation: < Describe the documentation added.>

Not needed only godoc.

[codecov]

Codecov Report

Merging #1297 into master will increase coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1297      +/-   ##
==========================================
+ Coverage   89.42%   89.49%   +0.06%     
==========================================
  Files         212      213       +1     
  Lines       15170    15179       +9     
==========================================
+ Hits        13566    13584      +18     
+ Misses       1170     1163       -7     
+ Partials      434      432       -2     

Impacted Files	Coverage Δ
consumer/consumererror/permanenterror.go	77.77% <ø> (ø)
consumer/consumererror/partialerror.go	100.00% <100.00%> (ø)
processor/queuedprocessor/queued_processor.go	79.23% <100.00%> (+2.85%)	⬆️
service/builder/exporters_builder.go	74.28% <0.00%> (+1.42%)	⬆️
exporter/opencensusexporter/opencensus.go	49.45% <0.00%> (+4.39%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e7ab219...22d4e11. Read the comment docs.

[owais]

Does this mean exporters need to know about the existence of queued processor and may be use it as a dependency (to import the error type)? Can we may be move the error type to the components or some other core package and generalize it so it's not highly specific to queued retry? We could rename it to something generic and also rename the toRetry field to something like failures or failed. We'd also need different error types for metrics, traces and logs or may be we can have failedMetrics, failedTraces fields on the same error? Once we have this, exporters can freely chose to use return this error and any component in the pipeline before can add support to handle partial failures. This would enable people to implement custom error handling/retrying processors that can also support partial retries.

[pavolloffay]

Does this mean exporters need to know about the existence of queued processor and may be use it as a dependency

correct, currently exporters would have to import it if they want to use the error type.

We'd also need different error types for metrics, traces and logs or may be we can have failedMetrics, failedTraces fields on the same error?

A different error type would work, or a single type with multiple factory methods and getters for data types.

[pavolloffay]

I have moved the error to the consumer package and made it more generic.

[bogdandrutu]

Please rebase I made some refactoring in the qretry

[pavolloffay]

Rebased

[bogdandrutu]

Don't need else if because the previous returns. just an if

[bogdandrutu]

Will fix this in my metrics PR.