open-telemetry / open-telemetry/opentelemetry-python

OpenTelemetry Spans exported during async code execution yield varying number of spans when asserting in pytest

Open
#4,210 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
2.6k
Forks
1k
Avg merge
4d 15h
Merged PRs (30d)
19

Description

Describe your environment

OS: (e.g, Ubuntu)
Python version: (e.g., Python 3.8.10)
SDK version: (e.g., 1.25.0)
API version: (e.g., 1.25.0)

What happened?

https://github.com/googleapis/python-pubsub/pull/1254/files -> This was an interim fix I put in for the time being. But the issue that was observed was that both the number and order of spans exported to the pytests would differ across runs. This was not reproducible locally when run on several hundred runs, but would show up in the presubmits occasionally. The exact code could be looked at in the linked issue above, but at a high level:

class Foo():

   def a():
      // start and end spans 1, 2 - so these are expected to be exported to pytests(and this is the case when the pytests are run locally
     // start span 3, but don't end it.
     asynchronously invoke b()
 
  // run async, but invoked by a()    
  def b():
     // end span 3
     // start and end span 4

What I expected in the pytest unit tests for a() is that spans 1 and 2 show up as finished spans. And spans 3 and 4 don't show up. This was the case in every local execution of the test. But when the presubmits run on Github, I see that some times, the asserted spans also include spans 3 and 4, and the ordering of spans 1,2,3,4 also vary.

  1. Could you please let me know why this could be happening?
  2. What's the recommended way to handle / test this scenario?
Steps to Reproduce

Mentioned above

Expected Result

Spans exported and hence assertable in the pytest should be deterministic

Actual Result

Spans exported are non-deterministic.

Additional context

No response

Would you like to implement a fix?

None

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked googleapis/python-pubsub pull request #1254 and the pytest unit-test scenario described in this issue, focusing on asynchronous span completion and export timing. Done should include a confirmed explanation for the nondeterministic span count and ordering, plus documented or tested guidance for asserting spans reliably.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
observability
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.