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

Warning "Can't call method "get_context" on an undefined value" when using "start_active_span" "child_of" #34

Open
marrem opened this issue Apr 3, 2024 · 1 comment

Comments

@marrem
Copy link

marrem commented Apr 3, 2024

I get this warning:

(in cleanup) Can't call method "get_context" on an undefined value at /usr/local/share/perl/5.36.0/OpenTracing/Implementation/DataDog/Client.pm line 439 during global destruction.

When doing this:

sub receive {
        # Mock receieve headers....
	my $received_headers = HTTP::Headers->new();
	$received_headers->header('X-Datadog-Parent-Id' => '6498514476147820228');
	$received_headers->header('X-Datadog-Trace-Id' => '7906975651567419548');
	my $received_opentracing_context = $tracer->extract_context( $received_headers );

	say "---- received span context -----";
	print Dumper($received_opentracing_context);

	my $scope = $tracer->start_active_span('receive', 'child_of' => $received_opentracing_context);
	say "---- receive span context";
	print Dumper($scope->get_span()->get_context());
	start(); # which starts / closes it's own child span.

	$scope->close();
}

The 'received' spanId is correctly propagated, but I get a warning at the end. I don't know how to force a stack trace at that place.
start() doesn't throw an exception. So $scope->close() is being called.

If I intentionally don't close the outer $scope I get the same warning plus: (in cleanup) Scope not programmatically closed before being demolished at (eval 473) line 23..

@vanHoesel
Copy link
Contributor

Hi @marrem,

I'm sorry for the late response, and I'm afraid you and I need to discuss how you have tried to setup your OpenTracing / DataDog environment.

I think I have found part of the issue, which might be related to our internal HTTP client that tries to send a HTTP request to the dd-tracer-agent (is that how it is called ?). When that request fails, the internal client can become unstable. Which, of course, needs fixing.

However, it also shows me that your environment is not working correctly.

I'll reach out to you on LinkedIn to further discuss part of the problem, as I will investigate what can be done to make this module more robust and keep folks informed what is really going on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants