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

How to Ignore context.Canceled Error #5703

Open
Ajilagi opened this issue Aug 10, 2024 · 1 comment
Open

How to Ignore context.Canceled Error #5703

Ajilagi opened this issue Aug 10, 2024 · 1 comment
Assignees
Labels
area:trace Part of OpenTelemetry tracing enhancement New feature or request pkg:SDK Related to an SDK package

Comments

@Ajilagi
Copy link

Ajilagi commented Aug 10, 2024

I have a service that uses context cancelation by design to stop any previous process if the other/newest one is coming. The way I make a span is exactly similar to the any example from the instrumentation such as below

Mostly, the span starts from the http server wrapper, and then it produces children span from the http client wrapper, grpc client wrapper, or sql client wrapper ( I didn't manually start/end any parent/children span)

My problem is when it comes to my instrumentation such as otelhttp, otelgrpc, otelsql, etc. The instrumentation always produces a span with the otel.status: 'ERROR' and it leads to an increased error rate.

Is there any way to replace/modify any field by configuring the tracer/trace provider/span processor or anything on a specific service? I don't want to add any changes to the collector, because it is only an exception in one of my services.

I've found a possible way of using the SpanProcessor, the idea is I could use the OnEnd func to filter the context.Canceled error. But, there's an issue because the OnEnd function only receive the ReadOnlySpan. What I want to do is to get rid of the otel.status: 'ERROR' field, not to drop the entire span. Are there any ideas to solve my usecase?

type SpanProcessor interface {
// DO NOT CHANGE: any modification will not be backwards compatible and
// must never be done outside of a new major release.
// OnStart is called when a span is started. It is called synchronously
// and should not block.
OnStart(parent context.Context, s ReadWriteSpan)
// DO NOT CHANGE: any modification will not be backwards compatible and
// must never be done outside of a new major release.
// OnEnd is called when span is finished. It is called synchronously and
// hence not block.
OnEnd(s ReadOnlySpan)
// DO NOT CHANGE: any modification will not be backwards compatible and
// must never be done outside of a new major release.
// Shutdown is called when the SDK shuts down. Any cleanup or release of
// resources held by the processor should be done in this call.
//
// Calls to OnStart, OnEnd, or ForceFlush after this has been called
// should be ignored.
//
// All timeouts and cancellations contained in ctx must be honored, this
// should not block indefinitely.
Shutdown(ctx context.Context) error
// DO NOT CHANGE: any modification will not be backwards compatible and
// must never be done outside of a new major release.
// ForceFlush exports all ended spans to the configured Exporter that have not yet
// been exported. It should only be called when absolutely necessary, such as when
// using a FaaS provider that may suspend the process after an invocation, but before
// the Processor can export the completed spans.
ForceFlush(ctx context.Context) error
// DO NOT CHANGE: any modification will not be backwards compatible and
// must never be done outside of a new major release.
}

@XSAM
Copy link
Member

XSAM commented Aug 10, 2024

A newly defined OnEnding method for SpanProcessor from open-telemetry/opentelemetry-specification#4024 seems to fulfill such a use case, though we haven't implemented this.

I am interested in implementing this method if other @open-telemetry/go-maintainers are OK with adopting this at an early stage.

@XSAM XSAM added area:trace Part of OpenTelemetry tracing pkg:SDK Related to an SDK package enhancement New feature or request labels Aug 13, 2024
@XSAM XSAM self-assigned this Aug 28, 2024
@dmathieu dmathieu assigned dmathieu and unassigned XSAM Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:trace Part of OpenTelemetry tracing enhancement New feature or request pkg:SDK Related to an SDK package
Projects
None yet
Development

No branches or pull requests

3 participants