Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: new interface for ExportResult #1569 #1643

Merged
merged 9 commits into from
Nov 4, 2020

Conversation

vmarchaud
Copy link
Member

There is 2 goals for this PR:

  • Remove FAILED_RETRYABLE result since it has been removed from the spec and we expect exporter to handle this.
  • Add an optional error inside the result so the error is correctly handled at one place (on the Controller for metrics and SpanProcessor for spans). Previously every exporter had to use the globalErrorHandler to report the error which made multiple errors appears (one from the exporter and one for the upstream component that called it)

The design is the same as the Golang implementation: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/sdk.md#go-spanexporter-interface

Fixes #1569

@vmarchaud vmarchaud self-assigned this Oct 31, 2020
@vmarchaud vmarchaud added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Oct 31, 2020
@vmarchaud vmarchaud force-pushed the export-result-update branch 3 times, most recently from c1d28f8 to ccdc74e Compare October 31, 2020 21:11
@codecov
Copy link

codecov bot commented Oct 31, 2020

Codecov Report

Merging #1643 into master will increase coverage by 0.11%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##           master    #1643      +/-   ##
==========================================
+ Coverage   91.19%   91.31%   +0.11%     
==========================================
  Files         165      165              
  Lines        5066     5066              
  Branches     1037     1044       +7     
==========================================
+ Hits         4620     4626       +6     
+ Misses        446      440       -6     
Impacted Files Coverage Δ
...etry-exporter-prometheus/src/PrometheusExporter.ts 90.16% <50.00%> (ø)
...ckages/opentelemetry-exporter-jaeger/src/jaeger.ts 86.84% <60.00%> (+1.12%) ⬆️
...ges/opentelemetry-metrics/src/export/Controller.ts 79.16% <66.66%> (+33.71%) ⬆️
...telemetry-tracing/src/export/BatchSpanProcessor.ts 90.90% <66.66%> (-1.28%) ⬇️
...elemetry-tracing/src/export/SimpleSpanProcessor.ts 82.75% <75.00%> (-2.43%) ⬇️
packages/opentelemetry-core/src/ExportResult.ts 100.00% <100.00%> (ø)
...ry-exporter-collector/src/CollectorExporterBase.ts 91.30% <100.00%> (-0.54%) ⬇️
...elemetry-exporter-zipkin/src/platform/node/util.ts 96.66% <100.00%> (-0.31%) ⬇️
...ckages/opentelemetry-exporter-zipkin/src/zipkin.ts 100.00% <100.00%> (ø)
...emetry-metrics/src/export/ConsoleMetricExporter.ts 62.50% <100.00%> (ø)
... and 3 more

Copy link
Member

@dyladan dyladan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. One quick note about returning an error matching the go impl: in go this is the only way to report an error as there is no throw/try/catch. I'm still fine with it though.

@@ -72,7 +72,7 @@ export function sendWithXhr(
onSuccess();
} else {
const error = new collectorTypes.CollectorExporterError(
xhr.responseText,
`Failed to export with XHR (status: ${xhr.status})`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason for this change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on what the collector report (which itself depend on upstream exporters) you can have a empty text. I prefered to opt for this generic text so user get an error message every time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xhr.status already is passed to CollectorExporterError. Maybe it is better to have xhr.responseText || "Failed to export with XHR"?

@vmarchaud
Copy link
Member Author

One quick note about returning an error matching the go impl: in go this is the only way to report an error as there is no throw/try/catch. I'm still fine with it though.

I agree that it would be better if we could only use throw/try/catch (with async/await), however since we have a callback interface i prefered to keep the callback system (which i think is required in the spec ?).

@dyladan
Copy link
Member

dyladan commented Nov 2, 2020

One quick note about returning an error matching the go impl: in go this is the only way to report an error as there is no throw/try/catch. I'm still fine with it though.

I agree that it would be better if we could only use throw/try/catch (with async/await), however since we have a callback interface i prefered to keep the callback system (which i think is required in the spec ?).

I agree. I was just mentioning it for completeness and for others who might question it.

Copy link
Member

@obecny obecny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one minor thing, other that that lgtm.

Should this have a breaking label ?


collectorExporter.export(metrics, result => {
assert.deepStrictEqual(result.code, ExportResultCode.FAILED);
assert.ok(result.error?.message.includes('cannot send'));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the message is still sendBeacon - cannot send so why shorter check then ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i just rewrote the code without thinking about what was in place, i will add it back


collectorTraceExporter.export(spans, result => {
assert.deepStrictEqual(result.code, ExportResultCode.FAILED);
assert.ok(result.error?.message.includes('cannot send'));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here the same sendBeacon - cannot send ?

@vmarchaud
Copy link
Member Author

Should this have a breaking label ?

Yeah i believe, specially for vendor exporters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ExportResult.FAILED_RETRYABLE isnt spec compliant
3 participants