Unexpectedly long traces are getting created for network requests and manually created spans

[mukesh-mt]

The trace created by URLSession instrumentation as well as some manual created spans have very long duration.

[ganeshnj]

@mukesh-mt thanks for filing the issue.

Could you provide reproduction steps?

[mukesh-mt]

I am able to reproduce this when I put the app in background while some api calls were executing, the total time also includes the time when app was in background.

[hannadutkiewicz]

We're experiencing the same issue. It's also reproducible when the app goes into background while a custom span was started. I don't see any method to pause the started span when app goes into background. How do you think we should handle this?

[mariedm]

Hello, thank you all for reporting this issue. We will work on a fix and keep you updated.

[ncreated]

Hey @hannadutkiewicz, @mukesh-mt 👋,

Please note the two attributes we add to spans:

• is_background: If the span started and ended in the background.
• foreground_duration: The total duration of the span in the foreground, in seconds.

For more context, see this PR.

Both attributes can be used to filter spans in your queries.

There’s no issue with seeing long spans; they reflect the full duration of the URLSessionTask operation. This is expected behavior, so I’m closing this issue.

If you’d like to propose specific handling for spans that end or continue in the background, please create a feature request. Defining a generic behavior is tricky — stopping spans automatically when the app goes to the background will fix the "long spans" issue, but it will also cause problems for those who don’t expect this behavior for shorter spans.